it had a command-line solver. In order to do this, I've had to
expose the internal region numbering because the solver has to have
some way to state which region it means; and in any case it's also
useful to have human-visible region numbering so that two people can
discuss a puzzle they're solving together. So pressing L during play
now toggles the display of region numbers; and `mapsolver' uses
those same numbers when showing its working and its solutions.
[originally from svn r6244]
place in r6190. I'm quite pleased that I didn't have to modify the
printing infrastructure _at all_ to make this work; the only source
change required outside windows.c was the addition of a trivial
utility function midend_get_params(), and that was for the benefit
of bulk puzzle generation rather than anything to do with actual
printing.
As far as I can tell, all printable puzzles now print almost
indistinguishably from the way they print under Unix. If you look
closely the font is slightly different, and the Windows standard
hatching doesn't seem to be quite as nice as the kind I did by hand
in ps.c (and, particularly annoyingly, hatched areas don't show up
at all for me when I print to a file and use gv, though they come
out fine on the printer itself); but it's all there, and it all
works.
[originally from svn r6193]
[r6190 == af59dcf6858264103bbc621761feee3aed5aaf2a]
as seen by the back ends from the one implemented by the front end,
and shoved a piece of middleware (drawing.c) in between to permit
interchange of multiple kinds of the latter. I've also added a
number of functions to the drawing API to permit printing as well as
on-screen drawing, and retired print.py in favour of integrated
printing done by means of that API.
The immediate visible change is that print.py is dead, and each
puzzle now does its own printing: where you would previously have
typed `print.py solo 2x3', you now type `solo --print 2x3' and it
should work in much the same way.
Advantages of the new mechanism available right now:
- Map is now printable, because the new print function can make use
of the output from the existing game ID decoder rather than me
having to replicate all those fiddly algorithms in Python.
- the new print functions can cope with non-initial game states,
which means each puzzle supporting --print also supports
--with-solutions.
- there's also a --scale option permitting users to adjust the size
of the printed puzzles.
Advantages which will be available at some point:
- the new API should permit me to implement native printing
mechanisms on Windows and OS X.
[originally from svn r6190]
(This puzzle is theoretically printable, but I haven't added it in
print.py since there's rather a lot of painful processing required
to get from the game ID to the puzzle's visual appearance. It
probably won't become printable unless I get round to implementing a
more integrated printing architecture.)
[originally from svn r6186]
Also in this checkin (committed by mistake - I meant to do it
separately), a behind-the-scenes change to Slant to colour the two
non-touching classes of diagonals in different colours. Both colours
are set to black by default, but configuration by way of
SLANT_COLOUR_* can distinguish them if you want.
[originally from svn r6164]
nikoli.co.jp (which has quite a few puzzles that they don't seem to
have bothered to translate into English).
Minor structural change: the disjoint set forest code used in the
Net solver has come in handy again, so I've moved it out into its
own module dsf.c.
[originally from svn r6155]
generation) from a simple but rather fun Flash game I saw this
morning.
Small infrastructure change for this puzzle: while most game
backends find the midend's assumption that Solve moves are never
animated to be a convenience absolving them of having to handle the
special case themselves, this one actually needs Solve to be
animated. Rather than break that convenience for the other puzzles,
I've introduced a flag bit (which I've shoved in mouse_priorities
for the moment, shamefully without changing its name).
[originally from svn r6097]
command-line programs (solosolver, patternsolver, mineobfusc) to be
built as part of the normal Makefiles. This means mkfiles.pl now has
the capability to compile a source file more than once with
different #defines. Also, fixes for those auxiliary programs and one
fix in midend.c which the Borland compiler objected to while I was
testing its makefile generation.
[originally from svn r6066]
generator. The generator is lacking in almost any kind of finesse,
but it produces puzzles which at least _I_ find plausibly puzzling.
[originally from svn r6052]
introduces a few new utility functions in misc.c, one of which is
the bitmap obfuscator from Mines (which has therefore been moved out
of mines.c).
[originally from svn r5992]
(solving it only requires matrix inversion over GF(2), whereas
several of the other puzzles in this collection are NP-complete in
principle), but it's a fun enough thing to play with and is
non-trivial to do in your head - especially on the hardest preset.
[originally from svn r5967]
takes place in a checked-out copy. Also added mkunxarc.sh which does
the same version determination before building its archive.
[originally from svn r5782]
ends. Versioning will be done solely by Subversion revision number,
since development on these puzzles is very incremental and gradual
and there don't tend to be obvious points to place numbered
releases.
[originally from svn r5781]
platform-dependent code in puzzles.h (ick), which in turn depended
on the magic symbol MAC_OS_X being defined by mkfiles.pl itself
(yuck). Suddenly realised I can do much better simply by putting it
in an OS X makefile extras section in Recipe, and removing both
previous hacks. Much nicer.
[originally from svn r5191]
of the manual using Halibut (with one additional magic tag in the
<HEAD> section), stuck it in the right part of the application
bundle, referenced it in Info.plist, and added a Help menu.
Everything else was automatic. Not bad!
[originally from svn r5190]
Mac OS X application bundle, and provided an icon for Puzzles.
Also renamed the OS X source file from macosx.m to osx.m, so that it
can sit beside other things such as osx-info.plist and not cause
enormously long filenames.
[originally from svn r5179]
puzzles are compiled together into a single monolithic application
which allows you to select each one from one of its menus.
[originally from svn r5173]
is (a) pretty feeble, and (b) means that although Net seeds transfer
between platforms and still generate the same game, there's a
suspicious discrepancy in the typical seed _generated_ by each
platform.
I have a better RNG kicking around in this code base already, so
I'll just use it. Each midend has its own random_state, which it
passes to new_game_seed() as required. A handy consequence of this
is that initial seed data is now passed to midend_new(), which means
that new platform implementors are unlikely to forget to seed the
RNG because failure to do so causes a compile error!
[originally from svn r4187]
are now expected to provide a list of `presets' (game_params plus a
name) which are selectable from the menu. This means I can play
both Octahedron and Cube without recompiling in between :-)
While I'm here, also enabled a Cygwin makefile, which Just Worked.
[originally from svn r4158]
