more than 36 distinct symbols (it runs out of alphanumerics), check
this in validate_params. I hate to do this, since I like puzzle
sizes to at least be open-ended in _principle_, but in this case
there's a fundamental UI limitation which won't be fixed by getting
a faster CPU.
[originally from svn r6098]
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]
do during construction which massively increases (by over a factor
of four with default parameters) the probability that any given
randomly generated grid will be uniquely solvable.
[originally from svn r6096]
- use the new `shuffle' utility function in a couple of places
- remove the random_state parameter from solver(). It was there
because I initially wanted to use the same solver for grid
generation, but since I had to abandon that plan the solver now
doesn't have any need for randomness at all.
[originally from svn r6093]
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]
by the midend every time the game state changed _other_ than as a
result of make_move(), on the basis that when the game state changed
due to make_move() the game backend had probably noticed anyway.
However, when make_move() split up, this became more fiddly: if the
game_ui had to be updated based on some property of the final game
state, then execute_move() couldn't do it because it didn't have a
pointer to the game_ui, but it was fiddly to do it in
interpret_move() because that didn't directly have a copy of the
finished game state to examine. Same Game (the only game to be
affected) had to deal with this by actually having interpret_move()
_call_ execute_move() to construct a temporary new game state,
update the UI, and then throw it away.
So now, game_changed_state() is called _every_ time the current game
state changes, which means that if anything needs doing to the
game_ui as a result of examining the new game state, it can be done
there and save a lot of effort.
[originally from svn r6087]
button interface (same button to open a closed square or to clear
around an open one) to be a massive help, there is one circumstance
in which it frequently kills me: if I click down on an open square I
want to clear around, then the mouse pointer accidentally drifts
over on to the nearest closed square before I release, I'll end up
opening that square instead and (usually) dying. So this checkin
causes Mines to note which type of square I left-clicked on, and to
do nothing if the button release is on the other type.
[originally from svn r6086]
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]
capability added to it, to be used only when all else fails, and is
simply called `solver'. This means that:
- solving of 5x5 Trivial grids using the `Solve' function, which
previously hung for ages because rsolve happened to take a wrong
turning at the start, is now zippy
- solosolver doesn't require the confusing -r and -n options
- solosolver can show its working even for Unreasonable grids.
Unfortunately, the new unified solver still isn't suitable for grid
generation. After it proved to be so much faster at solving 5x5s, I
hoped to be able to substitute it for rsolve during generation and
gain additional speed in 5x5 generation too; but no luck, because
it's slower _per recursion level_, and although during solving it
makes up for this by needing very few levels, there is a lot of
_unavoidable_ recursion during generation, especially at 5x5. A
hybrid strategy which starts off with rsolve and switches to the
unified solver at a critical point proved unsatisfactory as well,
because the critical point changes depending on the vagaries of the
recursion and can't be pinpointed easily. So rsolve is still in
there, only renamed `gridgen' because that's now all it's good for.
[originally from svn r6077]
- reinstate the initialisation of ds->w and ds->h in guess.c, which
I'd accidentally removed during game_size() refactoring
- reorganise Net's interpret_move() so that my uncommitted patch
for drag-based UI (which he uses on the Palm port) will apply
more easily
- the interpret_move() changes make it easy to have a single move
type which rotates a tile by 180 degrees, so this is now provided
via the `F' key (but there's no spare button available to provide
it via the mouse).
[originally from svn r6070]
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]
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]
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]
they will only be processed as special by the midend if unwanted by
the backend. This causes 5x5 Solo to become just about playable,
because you can now click in a square and type `n'. However, typing
`n' when a square is not selected will revert to the normal
behaviour of starting a new game.
(This isn't particularly ideal, I know, but it's better than
nothing.)
[originally from svn r6048]
constraint: because some front ends interpret `draw filled shape' to
mean `including its boundary' while others interpret it to mean `not
including its boundary' (and X seems to vacillate between the two
opinions as it moves around the shape!), you MUST NOT draw a filled
shape only. You can fill in one colour and outline in another, you
can fill or outline in the same colour, or you can just outline, but
just filling is a no-no.
This leads to a _lot_ of double calls to these functions, so I've
changed the interface. draw_circle() and draw_polygon() now each
take two colour arguments, a fill colour (which can be -1 for none)
and an outline colour (which must be valid). This should simplify
code in the game back ends, while also reducing the possibility for
coding error.
[originally from svn r6047]
the current midend state even if you don't subsequently enter a
valid one. Reorganise midend_game_id_int() so that (just like
midend_deserialise()) it does all its error checking before altering
anything in the midend's persistent data, so that it either succeeds
completely or fails before doing anything at all.
[originally from svn r6045]
causing invalid move descriptions to be returned from
interpret_move() and then failing an assertion when execute_move()
refused them.
[originally from svn r6044]
did I miss this before? It just caused a segfault for me, which is
entirely fair enough, but I've no idea why it didn't fail before!
[originally from svn r6043]
- most game_size() functions now work in doubles internally and
round to nearest, meaning that they have less tendency to try to
alter a size they returned happily from a previous call
- couple of fiddly fixes (memory leaks, precautionary casts in
printf argument lists)
- midend_deserialise() now constructs an appropriate drawstate,
which I can't think how I overlooked myself since I _thought_ I
went through the entire midend structure field by field!
[originally from svn r6041]
for a past guess caused strangeness up to and including segfault,
thanks to bad bounds checking. Well spotted John Sullivan.
[originally from svn r6040]
midend.c. Also I've added an experimental front end in gtk.c only:
`Save' and `Load' options on the Game menu, which don't even show up
unless you define the magic environment variable
PUZZLES_EXPERIMENTAL_SAVE. Once I'm reasonably confident that the
whole edifice is plausibly stable, I'll take that out and turn it
into a supported feature (and also implement it in OS X and Windows
and write documentation).
[originally from svn r6030]
retired, and replaced with a simple string. Most of the games which
use it simply encode the string in the same way that the Solve move
will also be encoded, i.e. solve_game() simply returns
dupstr(aux_info). Again, this is a better approach than writing
separate game_aux_info serialise/deserialise functions because doing
it this way is self-testing (the strings are created and parsed
during the course of any Solve operation at all).
[originally from svn r6029]
