Stop the analysis pass in Loopy's redraw routine from being
conditionalised on !ds->started, so that we still do all the looping
over everything even if we know it's all going to be redrawn. This is
because deciding how much needs redrawing is not the only important
thing in those loops - they also set up arrays like ds->clue_error,
which tell the individual redraw functions _what_ to draw.

Fixes a bug in which, if you start a Loopy game and make moves causing
a clue to light up red for an error and then save your game, loading
the same save file at the start of a Loopy run would fail to highlight
the erroneous clue.

(This commit diff looks large, but actually it changes almost nothing
but whitespace.)

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9751 cda61777-01e9-0310-a592-d414129be87e

Bring Pearl's game-completion handling in line with my usual practice:
the 'completed' flag is not reset if you make a new move transforming
a solved game into an unsolved state, so the game won't flash again if
you manually erase and redraw a line segment (though it still will if
you undo and redo past the first solved state in the undo history).

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9750 cda61777-01e9-0310-a592-d414129be87e

Revamp of the Windows command-line parsing and puzzle-loading code.

The Windows puzzles now accept similar command-line syntax to the GTK
ones, in that you can give them either a game ID (descriptive, random
or just plain params) or the name of a save file. Unlike the GTK ones,
however, the save file interpretation is tried first; this is because
some puzzles (e.g. Black Box) will interpret any old string as a valid
(if boring) game ID, and unlike the GTK puzzles it's not feasible to
require users to disambiguate via a command-line option, because on
Windows a thing that might easily happen is that a user passes a save
file to a puzzle binary via 'Open With' in the GUI shell, where they
don't get the chance to add extra options.

In order to make this work sensibly in the all-in-one Windows app, I
had to get round to another thing I've been planning to do for a
while, which is to write a function to examine a saved game file and
find out which puzzle it's for. So the combined Windows binary will
auto-switch to the right game if you pass a save file on its command
line, and also if you use Load while the program is running.

Another utility function I needed is one to split the WinMain single
command line string into argv. For this I've imported a copy of
split_into_argv() from Windows PuTTY (which doesn't affect this
package's list of copyright holders, since that function was all my
own code anyway).

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9749 cda61777-01e9-0310-a592-d414129be87e

Pattern's display was broken for non-square puzzles, because
draw_numbers() was considerably confused between the width of the clue
border at the left and the height of the clue border at the top.
Unconfuse it (I think).

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9737 cda61777-01e9-0310-a592-d414129be87e

Actually do what the comment says at the top of main() regarding not
bombing out due to an option that we don't recognise but GTK will.
Somehow my basically workable plan had been completely nullified by
putting the error check in the wrong place.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9733 cda61777-01e9-0310-a592-d414129be87e

Fix overnight build failure last night, by making the new call to
gtk_widget_get_allocation conditional on GTK being new enough to have
that function.

I'm assuming until someone proves otherwise that if it isn't that new,
then it also isn't one of the versions of GTK which exhibit the bug
which that call was working around (since gtk_widget_get_allocation
came in 2.18, and the problem seems to have arisen since 2.20).

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9712 cda61777-01e9-0310-a592-d414129be87e

Work around an annoying GTK behaviour I noticed the other day on my
Ubuntu 12.04 machine. What seems to happen is that we set up a window
containing a menu bar, a drawing area and a status bar, and set the
size of the drawing area; then the window is displayed _without_ the
menu bar; then we reduce the drawing area's size request to (1,1) to
let the user resize the window smaller; and now GTK gets round to
constructing the menu bar, and the drawing area helpfully shrinks a
bit to make room for it.

My fix is to set a 'shrink pending' flag instead of shrinking the
drawing area's size request, and defer the actual shrink operation
until the menu bar and status bar are both present.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9711 cda61777-01e9-0310-a592-d414129be87e

A user points out that I could usefully clarify the Undead clue
semantics when a reflected sight-line crosses the same monster twice.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9694 cda61777-01e9-0310-a592-d414129be87e

Remove an unused variable spotted by gcc 4.6.3.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9682 cda61777-01e9-0310-a592-d414129be87e

New puzzle! 'Unruly', contributed by Lennard Sprong, is an
implementation of a puzzle usually called 'Tohu wa Vohu'.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9680 cda61777-01e9-0310-a592-d414129be87e

Make indentation consistent. (Somehow I forgot to do this before I
originally committed the puzzle, as I usually do.)

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9660 cda61777-01e9-0310-a592-d414129be87e

Forgot to add the new 'const' in the unfinished subdirectory. Oops.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9659 cda61777-01e9-0310-a592-d414129be87e

Oops, forgot to initialise changed_ascii on all paths in r9657.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9658 cda61777-01e9-0310-a592-d414129be87e

New rule: interpret_move() is passed a pointer to the game_drawstate
basically just so that it can divide mouse coordinates by the tile
size, but is definitely not expected to _write_ to it, and it hadn't
previously occurred to me that anyone might try. Therefore,
interpret_move() now gets a pointer to a _const_ game_drawstate
instead of a writable one.

All existing puzzles cope fine with this API change (as long as the
new const qualifier is also added to a couple of subfunctions to which
interpret_move delegates work), except for the just-committed Undead,
which somehow had ds->ascii and ui->ascii the wrong way round but is
otherwise unproblematic.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9657 cda61777-01e9-0310-a592-d414129be87e

Minor tweaks to Undead docs.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9656 cda61777-01e9-0310-a592-d414129be87e

New puzzle! Contributed by Steffen Bauer, an implementation of
'Haunted Mirror Maze', a game involving placing ghosts, zombies and
vampires in a grid so that the right numbers of them are visible along
sight-lines reflected through multiple mirrors.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9652 cda61777-01e9-0310-a592-d414129be87e

For the convenience of Linux package maintainers, add to Makefile.gtk
and Makefile.doc a command-line parameter 'BINPREFIX' which will be
prepended to all the game binary names. E.g. 'make BINPREFIX=sgt-' and
'make BINPREFIX=sgt- install', and correspondingly 'make -f
Makefile.doc BINPREFIX=sgt-'.

Also included in this commit by mistake, changes to singles.c to add
\n to the end of all its debug() statements. I meant to commit that
separately. Oops.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9606 cda61777-01e9-0310-a592-d414129be87e

Fix implicit split to @_. Also add 'use warnings', which would have
spotted it for me.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9605 cda61777-01e9-0310-a592-d414129be87e

Don't fail an assertion when setting up the provided clues at the
start of the solver, if they contradict each other. (Could trigger on
user-provided grids.)

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9594 cda61777-01e9-0310-a592-d414129be87e

Vary the behaviour of Mines's solve function depending on whether the
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!)

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9561 cda61777-01e9-0310-a592-d414129be87e

Fix a bug introduced by r9495 in which we try to write temporary NULs
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.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9558 cda61777-01e9-0310-a592-d414129be87e

Add a hacky environment variable that lets me arrange a soak-test of a
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!

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9549 cda61777-01e9-0310-a592-d414129be87e

Remove the speed optimisation in the stage 3 solver which makes the
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.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9548 cda61777-01e9-0310-a592-d414129be87e

Another uninitialised-variable fix, this one pointing out a real bug.
Simplest fix is to just remove the 'n' parameter from
solve_island_subgroup, replacing it with a robust island_countbridges.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9547 cda61777-01e9-0310-a592-d414129be87e

Add pointless initialisations to placate a gcc warning.

(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.)

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9546 cda61777-01e9-0310-a592-d414129be87e

Write a comment outlining a design for a rewritten faster solver.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9544 cda61777-01e9-0310-a592-d414129be87e

Bridges solver enhancement. In the stage 3 solver, we were considering
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

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9543 cda61777-01e9-0310-a592-d414129be87e

Bridges solver fix: in map_update_possibles, collect values from
maxh/maxv for squares between islands as well as on islands.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9542 cda61777-01e9-0310-a592-d414129be87e

Patch from Jonas Koelker to improve Filling's error highlighting: as
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.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9534 cda61777-01e9-0310-a592-d414129be87e

Patch from Jonas Koelker for the developer docs, fixing a couple of
editing errors and adding some comments about the necessary order of
midend operations called by a front end.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9533 cda61777-01e9-0310-a592-d414129be87e

GNUstep compatibility: ensure both endpoints are actually drawn by
draw_line, by the brute-force method of explicitly plotting them in
addition to the GUI's line-drawing operation.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9505 cda61777-01e9-0310-a592-d414129be87e

GNUstep compatibility: add a missing #include.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9504 cda61777-01e9-0310-a592-d414129be87e

GNUstep compatibility: avoid attempting blitter_save with a partially
out-of-bounds rectangle. Instead, take the intersection of the
rectangle with the window boundary and do a smaller operation on
what's left.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9503 cda61777-01e9-0310-a592-d414129be87e

GNUstep compatibility: stop using the API feature isFlipped/setFlipped
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 separates 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.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9502 cda61777-01e9-0310-a592-d414129be87e

GNUstep compatibility: remove an unused variable which the compiler
warned about.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9501 cda61777-01e9-0310-a592-d414129be87e

GNUstep compatibility: comment out some API calls that GNUstep
apparently doesn't have. Fortunately they were optional anyway.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9500 cda61777-01e9-0310-a592-d414129be87e

GNUstep compatibility: spell null selectors "NULL", not "nil".

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9499 cda61777-01e9-0310-a592-d414129be87e

Add a section to mkfiles.pl to build a makefile that compiles the OS X
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.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9498 cda61777-01e9-0310-a592-d414129be87e

Stop using the deprecated NSString stringWithCString: methods.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9495 cda61777-01e9-0310-a592-d414129be87e

Update the OS X makefile so I can build on Lion. Regrettably that
means I have to withdraw support for OS X 10.3 and PPC.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9494 cda61777-01e9-0310-a592-d414129be87e

Permit users to reconfigure the default setting for each puzzle using
another of those hacky environment variables.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9455 cda61777-01e9-0310-a592-d414129be87e

Add a difficulty exception to prevent Pearl spinning forever when
asked to generate a 5x5 Tricky puzzle. (Debian bug #667963)

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9454 cda61777-01e9-0310-a592-d414129be87e

Typo fix from Helge Kreutzmann, forwarded from Debian.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9453 cda61777-01e9-0310-a592-d414129be87e

Increase by 1 pixel the clip rectangle used to draw and erase the
Black Box finish button. Like the Guess blitter, it was assuming
non-expansion of circles.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9452 cda61777-01e9-0310-a592-d414129be87e

Swap a 'max' for a 'min', fixing an out-of-range colour component
being passed to the front end.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9451 cda61777-01e9-0310-a592-d414129be87e

Increase by 1 in every direction the size of the blitter used to save
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.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9450 cda61777-01e9-0310-a592-d414129be87e

Add an explicit -lm to the link lines in Makefile.gtk, after two users
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.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9448 cda61777-01e9-0310-a592-d414129be87e

Fix redundant redrawing in Pegs. Apparently it has always redrawn
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!

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9447 cda61777-01e9-0310-a592-d414129be87e

Change some instances of 'print $thing' to 'print $thing || ""', to
prevent annoying Perl warnings when $thing is undefined.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9446 cda61777-01e9-0310-a592-d414129be87e

Error checking in Pattern, which was until now the only remaining game
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.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9445 cda61777-01e9-0310-a592-d414129be87e

Comment the Mac build out of Buildscr, since I no longer have a
working Mac and hence can't build it any more.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9442 cda61777-01e9-0310-a592-d414129be87e

Patch from Jonas Koelker to add keyboard control support to Pearl.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9411 cda61777-01e9-0310-a592-d414129be87e

Tweak a conditional expression in pearl.c to work around a display bug
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.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9408 cda61777-01e9-0310-a592-d414129be87e

Fix one-character typo in r9405 which was breaking right-clicks.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9406 cda61777-01e9-0310-a592-d414129be87e

David Nickerson reports odd behaviour involving a drag start point
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).

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9405 cda61777-01e9-0310-a592-d414129be87e

Correct kdiff setting.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9403 cda61777-01e9-0310-a592-d414129be87e

Don't try to run solver_killer_sums on a Killer cage with only one
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.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9402 cda61777-01e9-0310-a592-d414129be87e

Fix a couple of typos in messages.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9401 cda61777-01e9-0310-a592-d414129be87e

David Nickerson reports that it's possible to lay a line over a 'no
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'.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9400 cda61777-01e9-0310-a592-d414129be87e

Arrgh! Revert r9395,r9396,r9397,r9398, all of which I just committed
by mistake in one go by running git-svn dcommit on the wrong branch.
Those were patches recently submitted by a user but which are not of
production quality (yet?) and I meant to keep them in my local
experimental repository. Sorry.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9399 cda61777-01e9-0310-a592-d414129be87e

Fixed decoding bug for dual grids

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9398 cda61777-01e9-0310-a592-d414129be87e

Added dual floret preset

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9397 cda61777-01e9-0310-a592-d414129be87e

Added "dual" option to grid generators

It is now possible to produce duals of all grids.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9396 cda61777-01e9-0310-a592-d414129be87e

Can now take the dual of a grid

Taking the dual of a grid creates a new grid with one vertex
for each face of the original and one face for each vertex. This
allows the easy introduction of a new grid type, the dual of the
octagonal grid, which is a square grid in which each square is split
into four triangles.

Of the grid types currently present, square is its own dual,
honeycomb is the dual of triangles, cairo is the dual of snub-squares,
kites is the dual of great-hexagonal, and the dodecagonal ones would
have vertices with twelve edges, probably not practical. The others
all have duals that would introduce new classes of puzzle.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9395 cda61777-01e9-0310-a592-d414129be87e

Sort out a bit of confusion between mouse- and keyboard-driven drags
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).

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9393 cda61777-01e9-0310-a592-d414129be87e

Move a debug statement at the end of new_clues from the caller (just
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.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9392 cda61777-01e9-0310-a592-d414129be87e

Add comments suggesting some solver upgrades to Light Up (perhaps for
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.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9388 cda61777-01e9-0310-a592-d414129be87e

The Light Up solver limits its recursion depth, so if it fails to find
a solution then it should not deduce that no solution exists. Change
wording of the error message returned from the Solve user action.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9387 cda61777-01e9-0310-a592-d414129be87e

Fix default parameter assignment in Light Up when validating an
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.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9386 cda61777-01e9-0310-a592-d414129be87e

Trivial and silly patch to allow users to configure the Signpost
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 :-)

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9384 cda61777-01e9-0310-a592-d414129be87e

It's a new year.
(It was a new year this time last year, too.)

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9382 cda61777-01e9-0310-a592-d414129be87e

Tweak right-click processing to be less finicky.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9381 cda61777-01e9-0310-a592-d414129be87e

New puzzle! Or rather, new-ish, because this one has been lying around
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').

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9379 cda61777-01e9-0310-a592-d414129be87e

Fix a bug causing premature defeatism in the Bridges solver. Deducing
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.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9377 cda61777-01e9-0310-a592-d414129be87e

Allow --save to work with --soln, causing saved game files to be
written out with the Solve operation having already been performed.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9375 cda61777-01e9-0310-a592-d414129be87e

Fix bug in error reporting for --save caused by freeing 'realname'
before the error messages wanted to use it.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9374 cda61777-01e9-0310-a592-d414129be87e

Fix bug in --save caused by failure to initialise ctx.error to zero
before later checking to see if an errno code was dumped in it.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9373 cda61777-01e9-0310-a592-d414129be87e

In Group, the keyboard-controlled cursor should respect user
rearrangement of the rows and columns.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9372 cda61777-01e9-0310-a592-d414129be87e

Remove the 'cheated' flag in Range's game_ui, which was stickily
remembering whether the player had ever used the hint or solve
functions, even if they then pressed undo (and even if they saved and
restored).

As far as Solve+Undo is concerned, this just brings Range into line
with common practice in the rest of my puzzles. On the other hand,
Range is the first time there's been a 'hint' function to consider in
this question, so here's a policy decision: the victory flash is not a
congratulation for a puzzle solved unaided, it's a confirmation that
you really have reached a correct solution and haven't made any
mistakes. So the only reason to omit the victory flash is if you've
used the Solve operation to go straight to a guaranteed-correct
solution _in a single move_; if you're using the hint button, there's
still scope for you to make mistakes in all your non-hint moves, so
the victory flash is still a useful indicator that you didn't.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9306 cda61777-01e9-0310-a592-d414129be87e

When we run out of background colours for chains and wrap back to the
beginning, we should wrap back to COL_B0+1 rather than COL_B0 itself,
so as not to reuse white. White should be special, and always indicate
a properly numbered square.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9305 cda61777-01e9-0310-a592-d414129be87e

Patch from Chris Boyle to fix Signpost's labelling when you have more
than 26 separate linked chains of unnumbered squares: we now wrap from
'z' to an Excel-like 'aa', 'ab', ..., instead of falling off z into
punctuation and control characters.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9304 cda61777-01e9-0310-a592-d414129be87e

Changed my mind about midend_is_solved: I've now reprototyped it as
midend_status(), and given it three return codes for win, (permanent)
loss and game-still-in-play. Depending on what the front end wants to
use it for, it may find any or all of these three states worth
distinguishing from each other.

(I suppose a further enhancement might be to add _non_-permanent loss
as a fourth distinct status, to describe situations in which you can't
play further without pressing Undo but doing so is not completely
pointless. That might reasonably include dead-end situations in Same
Game and Pegs, and blown-self-up situations in Mines and Inertia.
However, I haven't done this at present.)

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9179 cda61777-01e9-0310-a592-d414129be87e

Pass background colour as a parameter to draw_gts and draw_adjs, so
that we can pass -1 in calls from game_print(). Fixes a printing bug
in which all the adjs and gts were overlaid with giant black
rectangles! (Because COL_BACKGROUND doesn't mean the same thing in
that context.)

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9175 cda61777-01e9-0310-a592-d414129be87e

Fix segfault in Loopy printing, introduced when I added the dynamic
arrays 'textx' and 'texty' to the game_drawstate but failed to
initialise them in the temporary drawstate used by game_print().
Thanks to Arun Giridhar for spotting this.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9173 cda61777-01e9-0310-a592-d414129be87e

Having played Keen a bit following the clue-generation fix in r9165,
I've decided that the extremely low density of one-option
multiplication clues is not a universally good idea after all: it
seems to me to make puzzles _quantitatively_ harder, even if Keen's
difficulty-level system can't see any difference in the set of modes
of reasoning required at least once to solve the grid.

So I've readjusted the clue selection, so that multiplicative clues
with only one workable pair of factors are restored to 'good' status
at Normal difficulty level and below, and only considered less-than-
fully-desirable at Hard and above. I think that's a reasonable
compromise.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9170 cda61777-01e9-0310-a592-d414129be87e

Apply the rotation in Penrose grid descriptions by rotating in the
4-vector representation, rather than mucking about with sines and
cosines after grid generation. _Should_ make no difference in the
generated grids (there's a theoretical risk of an unlucky rounding
error just about managing to push some point in or out of bounds, but
I think it's vanishingly small), but simplifies the coordinate-
flattening procedure, and in particular increases its chance of
getting vertical lines actually vertical.

(Prior to this change, the game ID
10x10t12:G2554,-31,108_a3b12h0a212a3d102b2a23a2e3b01b0a2c2a0c0 was
generating a not-quite-vertical edge at top left, in the Java port but
not on Linux; I suspect differences in sin and cos as the cause of the
discrepancy. With the rotation done like this, the points'
x-coordinates are now computed without reference to their
y-coordinates.)

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9168 cda61777-01e9-0310-a592-d414129be87e

Apply a missing bit of r9164, which only broke the build with
-DDEBUGGING so I didn't notice it at the time.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9167 cda61777-01e9-0310-a592-d414129be87e

Portability fixes, mostly from James for Palm purposes. Mostly
additions of missing 'static' and explicit 'void' in parameter lists,
plus one or two other things like explicitly casting chars in variadic
argument lists to int and using DBL_MAX if HUGE_VAL isn't available.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9166 cda61777-01e9-0310-a592-d414129be87e

Having looked at Keen's clue selection code, I also notice that the
intended behaviour of classifying multiplication clues as low-quality
if they only left one possible pair of multiplicands has never
actually worked, because I should have compared the possible clue
count against 2 rather than 1 since the multiplicands can occur either
way round.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9165 cda61777-01e9-0310-a592-d414129be87e

Fix warnings generated by gcc 4.6.0 about variables set but not
thereafter read. Most of these changes are just removal of pointless
stuff or trivial reorganisations; one change is actually substantive,
and fixes a bug in Keen's clue selection (the variable 'bad' was
unreferenced not because I shouldn't have set it, but because I
_should_ have referenced it!).

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9164 cda61777-01e9-0310-a592-d414129be87e

Fix two memory leaks reported by Tiago Dionizio in recent Loopy
development.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9163 cda61777-01e9-0310-a592-d414129be87e

Forgot to set 'has_incentre' on triangular grids, which don't use
grid_face_add_new(). Oops.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9161 cda61777-01e9-0310-a592-d414129be87e

From James Harvey (via a period of collaborative polishing), a patch
to add two kinds of Penrose tiling to the grid types supported by
Loopy.

This has involved a certain amount of infrastructure work, because of
course the whole point of Penrose tilings is that they don't have to
be the same every time: so now grid.c has grown the capacity to
describe its grids as strings, and reconstitute them from those string
descriptions. Hence a Penrose Loopy game description consists of a
string identifying a particular piece of Penrose tiling, followed by
the normal Loopy clue encoding.

All the existing grid types decline to provide a grid description
string, so their Loopy game descriptions have not changed encoding.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9159 cda61777-01e9-0310-a592-d414129be87e

Oops: initialise that new 'has_incentre' flag to false, otherwise the
game will sometimes pick random incentres in place of the carefully
computed ones. Ahem.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9158 cda61777-01e9-0310-a592-d414129be87e

Move most of face_text_pos() into grid.c, leaving in loopy.c only the
part that converts from abstract grid coordinates into screen
coordinates. This should speed up window-resizing by eliminating
pointless reiteration of the complicated part of the algorithm: now
when a game_drawstate is renewed, only the conversion into screen
coordinates has to be redone.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9157 cda61777-01e9-0310-a592-d414129be87e

Replace my brute-force algorithm in face_text_pos with a more complex
but faster and more mathematically sensible one.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9156 cda61777-01e9-0310-a592-d414129be87e

Stop calling face_text_pos() for faces that don't need to have text in
them anyway. It's slow and pointless.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9155 cda61777-01e9-0310-a592-d414129be87e

Support user-specified extra link flags (XLFLAGS) in the Unix
makefile. Makes it easy to recompile for things like profiling.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9154 cda61777-01e9-0310-a592-d414129be87e

Fix mismatch between printf format strings and arguments in some
solosolver verbose diagnostics in X mode. Also added gcc-specific
prototypes with __attribute__((format)) to ensure they all get checked
in future.

Spotted by Arun Giridhar; segfault without this fix is reproducible by
'solosolver -v 3x3x:7_9e4_1c7d3e3d1b2_4e2c6e5_6b1d8e5d9c8_2e9_5'.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9151 cda61777-01e9-0310-a592-d414129be87e

Remove a stray diagnostic.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@9147 cda61777-01e9-0310-a592-d414129be87e