spins forever, but observes that raising the limit to 4x4 across all
grid types is not good for the complex grids like great-hexagonal.
Introduce per-grid minimum sizes using mad macro trickery.
(In fact, for each grid type I've put in a minimum size which _both_
dimensions must equal or exceed, plus another minimum size which _at
least one_ must equal or exceed; that permits both 3x4 and 4x3 Cairo
while disallowing 3x3.)
[originally from svn r8191]
on Windows at all?! Fix some departures from the C standard, mostly
declaring variables after a statement has already been issued in the
same block. MSVC is picky about this where gcc is forgiving, and TBH
I'd change the latter given the choice.
[originally from svn r8166]
Lambrou. Now capable of handling triangular and hexagonal grids as
well as square ones, and then a number of semiregular plane tilings
and duals of semiregular ones. In fact, most of the solver code
supports an _arbitrary_ planar graph (well, provided both the graph
and its dual have no self-edges), so it could easily be extended
further with only a little more effort.
[originally from svn r8162]
_conditionally_ able to format the current puzzle as text to be sent
to the clipboard. For instance, if a game were to support playing on
a square grid and on other kinds of grid such as hexagonal, then it
might reasonably feel that only the former could be sensibly
rendered in ASCII art; so it can now arrange for the "Copy" menu
item to be greyed out depending on the game_params.
To do this I've introduced a new backend function
(can_format_as_text_now()), and renamed the existing static backend
field "can_format_as_text" to "can_format_as_text_ever". The latter
will cause compile errors for anyone maintaining a third-party front
end; if any such person is reading this, I apologise to them for the
inconvenience, but I did do it deliberately so that they'd know to
update their front end.
As yet, no checked-in game actually uses this feature; all current
games can still either copy always or copy never.
[originally from svn r8161]
`clues' array being able to be -1, so we must explicitly declare it
as `signed char' or it will break on platforms whose default char is
unsigned.
[originally from svn r7636]
is mostly done with ifdefs in windows.c; so mkfiles.pl generates a
new makefile (Makefile.wce) and Recipe enables it, but it's hardly
any different from Makefile.vc apart from a few definitions at the
top of the files.
Currently the PocketPC build is not enabled in the build script, but
with any luck I'll be able to do so reasonably soon.
[originally from svn r7337]
checks. He thinks they were harmless (due to being followed by other
range checks in RIGHTOF_DOT and friends) but it clearly can't hurt
to fix them anyway.
[originally from svn r6709]
function, since it took no parameters by which to vary its decision,
and in any case it's hard to imagine a game which only
_conditionally_ wants a status bar. Changed it into a boolean data
field in the backend structure.
[originally from svn r6417]
was actually using it, and also it wasn't being called again for
different game states or different game parameters, so it would have
been a mistake to depend on anything in that game state. Games are
now expected to commit in advance to a single fixed list of all the
colours they will ever need, which was the case in practice already
and simplifies any later port to a colour-poor platform. Also this
change has removed a lot of unnecessary faff from midend_colours().
[originally from svn r6416]
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]
eliminates gratuitous duplication of the solver state every time it
goes round the main loop, in favour of the usual type of
`done_something' flag.
[originally from svn r6322]
- remove the backtracking `Hard' level, on the grounds that it was
incredibly slow and not really usable.
- introduce an `Easy' difficulty level below the standard one; many
people seem to find this puzzle unusually hard, so an easy level
is particularly helpful.
- highlight unfulfillable clue squares (but not yet any other types
of obvious error).
[originally from svn r6299]
