game_print(), wherever feasible. This fixes a specific bug in Loopy
(James H's new field ds->linewidth wasn't being set up, leading to
corrupted print output), but I've made the change in all affected
files because it also seems like a generally good idea to encourage
it for future games, to prevent other problems of this type.
There is one slight snag, which is that Map _can't_ do this because
its game_set_size() also initialises a blitter. I could fix this by
abstracting the common parts of Map's game_set_size() out into a
subfunction called by game_set_size() and also called directly by
game_print(); alternatively, I could introduce a means of
determining whether a `drawing *' was for screen or printing use.
Not sure which yet.
[originally from svn r6340]
to call game_set_size() twice on the same drawstate. Finally, a
definite decision: it isn't. Accordingly, midend.c arranges never to
do so, the devel docs state that puzzles may enforce by assertion
that it never happens, and the four puzzles which care (i.e. use
blitters) do so.
[originally from svn r6274]
cleanliness), plus he's enlarged the pencil-mark circles from
TILESIZE/8 to TILESIZE/7. Makes no difference at all (thanks to
integer division) when TILESIZE is the default of 20, but presumably
helps at some other tile sizes. Fine by me.
[originally from svn r6265]
a non-recursive level above Easy, which therefore moves the
recursive Hard mode further up still. Play-testing suggests that in
fact Tricky is often _harder_ than the old Hard mode, since the
latter had limited depth of recursion and would therefore spot
complex deductions only if it happened to start a recursion on the
right square; Tricky may be limited in the sophistication of its
complex deductions, but it never misses one, so its puzzles tend to
be hard all over.
Also in this checkin, a new source file `nullfe.c', containing all
the annoying stub functions required to make command-line solvers
link successfully. James wrote this for (the new) lightupsolver, and
I've used it to simplify the other stand-alone solvers.
[originally from svn r6254]
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]
- the exclamation mark was a bit dot-heavy
- allowing the indicator to be placed at a grid point as well as
half way between two grid points allows some much more natural
positioning.
[originally from svn r6234]
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]
