user is already in the 'dead' state when they press it. If so, we
reveal the rest of the mines in the grid as if it were the Windows
Minesweeper 'you lose' display, which provides information showing
what the user got wrong. (Otherwise they have to repeatedly flick back
and forth between Solve and Undo if they want to work out which flag
they placed wrongly.)
If you press Solve while alive, however, the existing behaviour
remains unchanged.
(This feature was suggested by Clive Jones a couple of weeks after I
first wrote Mines, and I've finally got round to doing it!)
[originally from svn r9561]
into a string which is usually a read-only string literal. Instead,
copy each segment into writable memory as we need it, and free it
afterwards.
[originally from svn r9558]
[r9495 == d0ff371b144d4bfe3cbfb062388347c08e431393]
solver I've just modified, by forcing every game generation to be
instantly followed by an attempt to re-solve the same game
_description_ without the aux_info.
I've hacked similar changes in to midend.c several times in the last
couple of months for one reason or another, and it's about time I
arranged not to have to recompile to do it!
[originally from svn r9549]
first loop only handle rightward or downward bridges (on the basis
that that way every bridge is looked at once rather than twice). This
seems to be breaking in the wake of recent changes to the solver, in
cases such as when island A is left of island B and has enough other
outgoing edges that only one bridge remains to potentially go to B,
but B is as yet unconstrained. In this situation the only code which
is able to adjust the maximum bridge count for that edge is the stage
3 solver (nothing else calls solve_join with is_max true), but it will
only do so if it _tries_ putting two bridges there and finds it
impossible, and when it starts from island A it won't even try.
Game ID which was insoluble just before this commit:
15x15m2:2a4d3b3c2h2d2a2a3c3w4a3m1d1a4a5a2d4d6e4q3e6a2a1e1b2g3a3o2g1d32l4b2c3a4c2b22l4a
This probably means I've done something else in recent checkins which
was not in accordance with the original solver design. However, this
fix will do for the moment.
[originally from svn r9548]
Simplest fix is to just remove the 'n' parameter from
solve_island_subgroup, replacing it with a robust island_countbridges.
[originally from svn r9547]
(I'm confident these can't happen. maxb is initialised whenever we
break from the first loop with y < h, and when we don't break from
that loop the second loop which uses maxb is run zero times. But gcc
can't work that out, sigh.)
[originally from svn r9546]
the possibility that an island might form an isolated subgraph by
connecting to one of its neighbours (and, if so, reducing the maximum
bridge count in that direction so that some bridge would have to go
elsewhere), but we were not also considering the possibility that it
might form an isolated subgraph by connecting to _more_ than one of
its neighbours. For instance, if you have a 3 adjacent to a 1, a 2 and
something else, then at least one bridge must go to the something-else.
Previously insoluble test case:
10x10m2:a2b4a5a2a2a1ga2d3b33a3a4c2aa3e1a22b2a4b4aa3b1a2b33a1e3aa2a1a2c23a3a3a4a2a
[originally from svn r9543]
well as marking a region as wrong if it has too many squares for the
number written in it, this patch now causes a region to be marked
wrong if it has too few squares _and no liberties_, so that it can't
just be one the user is intending to enlarge later.
[originally from svn r9534]
out-of-bounds rectangle. Instead, take the intersection of the
rectangle with the window boundary and do a smaller operation on
what's left.
[originally from svn r9503]
to translate y-coordinates from the default of up-from-bottom to the
down-from-top expected by these puzzles, because it doesn't work right
on GNUstep. Instead, we run the API in its default mode (probably a
more robust choice anyway) and translate coordinates manually in the
front end.
In the process, I've separated the processButton: method into one for
mouse buttons and one for keys, since that was the easiest way to
ensure the coordinates passed to the mid-end for the latter are -1,-1
_after_ translation rather than before.
[originally from svn r9502]
front end using GNUstep, yielding a Unix program built from the same
code. Should make it easier to check OS X behaviour without having to
move as far as a Mac :-) However, it doesn't compile as is, so I'll
apply fixes to the code until it does.
[originally from svn r9498]
the background under a Guess coloured peg in mid-drag. Currently it
assumes the circle doesn't extend into the next pixel, which the docs
for draw_circle warn might happen due to antialiasing.
[originally from svn r9450]
reported on the same day that this is now necessary since up-to-date
GNU tools won't consider it sufficient to have libm be a dependency of
other explicitly referenced libraries if you're directly referring to
the contents of libm yourself.
[originally from svn r9448]
every single peg and hole on the board, every time it did any kind of
redraw at all, because I forgot to update the array in the drawstate
indicating the last-drawn state of each position. And nobody's noticed
until now!
[originally from svn r9447]
that _ought_ to have it but did not.
I've tried to implement it before and found that the most obvious
approach was so effective as to constitute a spoiler, so this is a
deliberately weakened approach which in a bit of play-testing seems to
be a more sensible balance. It won't necessarily tell you at the very
instant you put a foot wrong, but it will at least ensure that (my
usual minimum standard) once you've filled in the whole grid you will
either have seen a victory flash, or an error indicator showing you
why not.
[originally from svn r9445]
in the Java build - which turns out to be a JVM bug in OpenJDK 6,
causing the NestedVM rendition of the expression (i==1?3:4) to be
mis-JITed. OpenJDK 7 appears not to do that any more, but this
equivalent (for these purposes) rephrasing should perturb the code
just enough to dodge the problem.
[originally from svn r9408]
persisting between separate mouse actions. Revamp all uses of the
ndragcoords field in an attempt to stamp that out: we now distinguish
between active drags (>0), a valid click but no drag yet (0), and a
totally invalid situation in which all mouse activity will be ignored
until the next fresh attempt (-1).
[originally from svn r9405]
square. It isn't equipped for it, and will try to handle it with the
4-square case and get confused. This can come up if the
DIFF_KINTERSECT pass before that split a cage, and will cause the
solver to miss valid solutions; e.g. 3x3kadu#802065940985372 would
generate an ambiguous puzzle before this change.
[originally from svn r9402]
line here' cross mark by dragging, and furthermore, that doing so puts
that grid edge into a stuck state that no UI action short of undo can
get it back out of. Fix drags to stop at crosses, and fix execute_move
to fault any move string that nonetheless somehow managed to try to
set a line over a cross without explicitly tagging it 'R'.
[originally from svn r9400]
in Rectangles. Mouse drags now take priority - you can't start a
keyboard drag while the mouse is held down, and starting a mouse drag
instantly cancels an unfinished keyboard drag - and also I've fixed an
assertion failure which would come up if you had the keyboard cursor
visible at the end of a mouse drag (by pressing arrow keys while the
mouse was held down).
[originally from svn r9393]
after return) to the callee (just before). Might print something
useful in the soak-test context (where that debug statement will now
be printed and previously wasn't), but the main aim is to remove the
variable 'ngen' at the main call site, which triggered a set-but-not-
used warning if the debug statement that printed it was compiled out.
[originally from svn r9392]
a new sub-recursive difficulty level?), inspired by a user emailing in
the game ID
18x10:gBc1b2g2e2d1b2c2h2e3c2dBd1g1bBb2b1fBbBb1bBgBd2dBi1h1c2b1dBe2bBdBb3cBg
which I was able to solve without backtracking by the use of these
techniques.
[originally from svn r9388]
a solution then it should not deduce that no solution exists. Change
wording of the error message returned from the Solve user action.
[originally from svn r9387]
incomplete parameter string: if the user hand-types a game ID along
the lines of '18x10:stuff', we should not assume SYMM_ROT4 in the
resulting game_params, since it'll be failed by validate_params.
[originally from svn r9386]
victory roll so that adjacent arrows rotate in opposite directions,
giving the impression that they're an interlocking field of gears.
Possibly even more brain-twisting than the original version :-)
[originally from svn r9384]
in the 'unfinished' directory for a while, and has now been finished
up thanks to James Harvey putting in some effort and galvanising me to
put in the rest. This is 'Pearl', an implementation of Nikoli's 'Masyu'.
The code in Loopy that generates a random loop along grid edges to use
as the puzzle solution has been abstracted out into loopgen.[ch] so
that Pearl can use it for its puzzle solutions too. I've also
introduced a new utility module called 'tdq' (for 'to-do queue').
[originally from svn r9379]
a better upper bound on the number of bridges leaving a given island
in a given direction was not counted as having 'done something'; so a
solver run could make several such deductions, but then terminate in
the belief that it hadn't achieved anything, when just going back
round the main solver loop would have enabled it to make further
deductions based on those new bounds.
[originally from svn r9377]
