whether the timer is currently going is no longer solely dependent
on the current game_state: it can be dependent on more persistent
information stored in the game_ui. In particular, Mines now freezes
the timer permanently once you complete a grid for the first time,
so that you can then backtrack through your solution process without
destroying the information about how long it took you the first time
through.
[originally from svn r6088]
with the obvious central hole it presents you with a randomly chosen
one of twelve other holes. The reason is, the central-hole starting
position is provably insoluble (proof given in comments), so instead
we pick from the ones that are actually possible.
[originally from svn r6083]
scheme in r6068, since this messed up the non-permanency of the non-limited
parameter.
[originally from svn r6069]
[r6068 == f3c95109c7b905f74b5f149eea21f68444c31ef7]
encode_params(). This is necessary for cases where generation-time parameters
that are normally omitted from descriptive IDs can place restrictions on other
parameters; in particular, when the default value of a relevant generation-time
parameter is not the one used to generate the descriptive ID, validation could
reject self-generated IDs (e.g., Net `5x2w:56182ae7c2', and some cases in
`Pegs').
[originally from svn r6068]
unpleasant and requiring lots of special cases to be taken care of
by every single game. The new interface exposes an integer `tile
size' or `scale' parameter to the midend and provides two much
simpler routines: one which computes the pixel window size given a
game_params and a tile size, and one which is given a tile size and
must set up a drawstate appropriately. All the rest of the
complexity is handled in the midend, mostly by binary search, so
grubby special cases only have to be dealt with once.
[originally from svn r6059]
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]
