Patch from Ben Hutchings to prevent memory leakage during Loopy game
generation.

[originally from svn r6708]

Tidy up comments.

[originally from svn r6601]

Introduce a new deductive mode in Slant's Hard level, which is the
generalisation of the previous deduction involving two 3s or two 1s
either adjacent or separated by a row of contiguous 2s. I always
said that was an ugly loop and really ought to arise naturally as a
special case of something more believable, and here it is.

The practical upshot is that Hard mode has just become slightly
harder: some grids generated by the new Slant will be unsolvable by
the old one's solver. I don't think it's become _excessively_ more
hard; I think I'm happy with the new difficulty level. (In
particular, I don't think the new level is sufficiently harder than
the old to make it worth preserving the old one as Medium or
anything like that.)

[originally from svn r6591]

"Hold" function in Guess was completely broken.
Fix it, add holds to the undo history (by analogy with Net), and save the
current holds in saved games.
Also fix a couple of unrelated minor issues with string encoding.

[originally from svn r6590]

I've been pondering whether to do this for months: turn the rather
washed-out yellow and green in Guess into their full-brightness pure
forms. This makes them hard to see against some backgrounds, so I'm
also surrounding all coloured pegs with black outlines. Looks a
little cartoony, but I think it's an overall improvement on the
previous look.

[originally from svn r6589]

Mines's error signalling is highly asymmetric: if you erroneously
believe a square to be empty, you find out instantly and lethally,
but if you erroneously believe a square to be full you can
occasionally (when it doesn't cause a complementary square to be
assumed empty) not notice until you find at the very end of the game
that you're one mine heavy. To help with this, here's an error
highlighting patch: any number square surrounded by an excess of
flags will now light up red. This should be an unintrusive change,
because it will never happen unless you make a mistake.

[originally from svn r6580]

Small docs patch from Phil Bordelon adding more history of Sudoku.

[originally from svn r6575]

Patch from Phil Bordelon to improve Bridges' appearance by adjusting
the font size.

[originally from svn r6573]

Tal Kelrich spotted that hitting `Solve' on a configuration which is
laser-indistinguishable from the right solution _but_ has a number
of balls outside the acceptable range does not report an error. His
example was the game ID w8h8m5M5:1e3e6e80fa3e16265ccef7ca , omitting
the rightmost ball in the second row.

[originally from svn r6542]

It's a new year.

[originally from svn r6513]
[this svn revision also touched halibut,putty,putty-website]

Revert a change in an assertion made in r6299. It was right the
first time, and now has a comment explaining why!

[originally from svn r6511]
[r6299 == c389f623f66fe5296f7ef5c66d88884607b82cff]

Add some random index terms. ("Sudoku" wasn't in the index!)

[originally from svn r6509]

Laurent Thioudellet reports that gcc4's ultra-cautious data flow
warnings require two more variables to be explicitly initialised. In
fact these variables are reliably initialised by a subfunction; gcc3
was happy to assume I knew what I was doing when it couldn't prove
they were definitely used uninitialised, whereas gcc4 apparently
takes the view that the onus is on me to allow it to prove they
_aren't_. I regard this as a step backwards, since the effect will
be to make explicit initialisation commonplace in cases where the
initialiser value is chosen arbitrarily and never expected to be
used, at which point (a) it will be less clear which initialisers
have genuine purpose and which are compiler-placating fluff, and (b)
valgrind's run-time uninitialised-data tracking will become less
useful. Still, the effect doesn't seem great as yet, so here's the
gcc4-placating checkin.

[originally from svn r6508]

I've just noticed a bug in the Inertia solver: if you call it on an
already-solved grid (i.e. no gems), it will still attempt to show
you a move you can make. Eliminate that special case.

[originally from svn r6507]

Correct w/h mixup in grid edge checks.

[originally from svn r6452]

Document Unix command-line options.

[originally from svn r6423]

Fix segfault in Tents' printing.

[originally from svn r6422]

Work around a couple of minor display issues with max bridges set to 4:

 - the highlighting for a set of 4 lines spilled outside the tile, so would
   leave white residue if undone;

 - the endpoints of sets of 4 lines were not completely overprinted by the
   circle of an island (at least on Windows), which was untidy.

Fixed by reducing the gap width for groups of lines which wouldn't otherwise
fit in a tile (only).

[originally from svn r6421]

Cleanup: relieve frontends of the duty to call
midend_rewrite_statusbar() and check the result against the last
string returned. This is now done centrally in drawing.c, and the
front end status bar function need only do what it says on the tin.

While I'm modifying the prototype of drawing_init(), I've also
renamed it drawing_new() for the same reason as random_new() (it
_allocates_ a drawing object, rather than just initialising one
passed in).

[originally from svn r6420]

Cleanup: remove the `just_used_solve' field from a number of games
which didn't actually need it. It was originally introduced in
Fifteen to suppress animation on Solve moves, but midend.c now does
that centrally unless the game specifically instructs it otherwise.
Therefore, just_used_solve is obsolete in all games which previously
used it. (Mines was even worse: it scrupulously maintained the
correctness of the field but never used it!)

Untangle is exempt from this cleanup: its `just_solved' field is
used to change the _length_ of the animation on Solve moves, not to
suppress it entirely, and so it has to stay.

[originally from svn r6419]

Forgot to update devel.but in r6417.

[originally from svn r6418]
[r6417 == eb2013efc0a6201d0e46de65c1a905b676d13d01]

Cleanup: it was absolutely stupid for game_wants_statusbar() to be a
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]

Cleanup: remove the game_state parameter to game_colours(). No game
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]

Noticed recently that bitcount16() isn't 16-bit clean due to signed
shift right. It doesn't actually matter in the current code since
the input word only ever uses the bottom 9 bits, but if I ever
extended Mines to work in a triangular grid then all 16 bits might
be required. Fix this now, while I'm cleaning things up, so that it
won't bite me unexpectedly in future.

[originally from svn r6415]

Cleanup: the `mouse_priorities' field in the back end has been a
more general-purpose flags word for some time now. Rename it to
`flags'.

[originally from svn r6414]

OS X frontend was directly calling the backend's wants_statusbar()
function, whereas it ought to have been calling the midend's one.

[originally from svn r6413]

Cleanup: rename random_init() to random_new(), because it actually
_allocates_ a random_state rather than just initialising one passed
in by the caller.

[originally from svn r6412]

New puzzle from James H: `Bridges', another Nikoli job.

[originally from svn r6409]

Miscellaneous fixes. Correct a comparison of y with w causing
assertion failures in portrait-type grids; retire an unused array in
the game generation function (my original generation strategy needed
it, but the final one didn't); correct a typo; further restrict the
generable sizes of game and include a special case for 4x4dt to
prevent a tight loop.

[originally from svn r6405]

Just noticed a longhand shuffling operation which I must have missed
when I converted them all into calls to shuffle().

[originally from svn r6404]

Janes H provides a small workaround for a Palm tools bug.

[originally from svn r6403]

Small error in solver diagnostics.

[originally from svn r6402]

Revamp of the control mechanism to permit drag- as well as
click-based control. Only used for right-dragging to clear a large
area to NONTENT.

[originally from svn r6400]

New puzzle: `Tents'. Requires a potentially shared algorithms module
maxflow.c. Also in this checkin, fixes to the OS X and GTK back ends
to get ALIGN_VNORMAL right. This is the first time I've used it! :-)

[originally from svn r6390]

loopy_diffnames[] isn't used, and provokes a warning on OS X.

[originally from svn r6389]

Yikes! I've only just noticed that this copy of tree234.c was still
using unwrappered malloc/free, leaving plenty of openings for out-
of-memory segfaults. Switch to using Puzzles's memory management,
which I should have done right at the start but can only assume I
forgot about.

[originally from svn r6388]

r6384 didn't go quite far enough. In fact, a grid square which
differs between oldstate and state in only the hint bit should not
have a flip animation even if hints_active is TRUE. Flip animations
should only happen for tiles which are changing their primary state.
(Put like that, it seems so obvious.)

Test case which demonstrates this fix to be right and r6384 to be
wrong: 3x3:101000000000000000000,300 . Hit Solve immediately and
then click on the red-highlighted squares.

[originally from svn r6385]
[r6384 == dd175e490a197026210ba4432eec6236971c6173]

Fixes for handling human-entered Flip games. The clicked-on square
always got a flip animation even when it wasn't one of the ones
being turned, and a square with no effect at all was still counting
as a move.

Since it's an invariant of Flip's internal generator that every
square includes itself as an effect, this never comes up in auto-
generated games.

[originally from svn r6384]

Richard Earnshaw points out that if you enter an out-of-range number
in the game description, the solver will fail to notice it and
overrun an array leading to assertion failure, silent wrong answers
or (in extreme cases) segfaults. Hence, validate_desc() now spots
them and kicks them out.

[originally from svn r6383]

Use game_set_size() to set up the temporary drawstate in
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]

Fix very strange indentation issue!

[originally from svn r6339]

Bug fix from James H: prevent LINEWIDTH ever reaching zero.

[originally from svn r6331]

Another optimisation patch from Mike, which (among other things)
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]

Optimisation patch from Mike: remember which squares we've entirely
finished dealing with, and don't do them again on the next loop.

[originally from svn r6312]

Patch from Mike: fix an array indexing error in the clue
highlighting, and adjust the presets.

[originally from svn r6303]

Patch from Mike:
 - 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]

I am again gormless! When I overhauled Solo's grid generator in
r6160, I completely failed to ensure that generated grids were _at
most_ the required difficulty. It appears to have been only random
chance that prevented a request for a Trivial puzzle from producing
Extreme. Here's a one-line fix.

[originally from svn r6298]
[r6160 == e55838bc9b0d173ca539d0cfe714495b5c12b9dd]

I found a slightly odd-looking line of code in this file a few days
ago, and nearly changed it to the obvious thing. After some thought,
though, I've decided the `bug' is better off unfixed, and added a
comment explaining why.

[originally from svn r6293]

Minor improvement to initial loop generation.

[originally from svn r6292]

Oops; left some rogue diagnostics in.

[originally from svn r6291]

Run the final solution-reduction pass in both directions, since
Gareth managed to find an example (10x8#458168771440033 in r6289)
where running it in only one direction failed to eliminate an
obviously redundant piece of path.

[originally from svn r6290]
[r6289 == b25fcc3f2621b0b41f3ae7cdabe57ed07f62d2c2]

Solve function for Inertia, using what's essentially an approximate
TSP algorithm.

[originally from svn r6289]

Marginally greater robustness in the face of solve_game() failing to
return an error message.

[originally from svn r6288]

Completely rewrite the loop-detection algorithm used to check game
completion, _again_. In r6174 I changed it from dsf to conventional
graph theory so that it could actually highlight loops as opposed to
just discovering that one existed. Unfortunately, yesterday I
discovered a fundamental graph-theoretic error in the latter
algorithm: if you had two entirely separate loops connected by a
single path, the path would be highlighted as well as the loops.

Therefore, I've reverted to the original dsf technique, combined
with a subsequent pass to trace around each loop discovered. This
version seems to do a better job of only highlighting the actual
loops.

[originally from svn r6283]
[r6174 == 2bd8e241a93165a99f5e2c4a2dd9c3b3b1e3c6f3]

Patch from James H which initialises a couple of Windows API object
handles to NULL before accidentally trying to use them for anything.

[originally from svn r6282]

I arranged that dying after the game was already completed didn't
increment the deaths counter. In doing so, I incorrectly handled the
borderline case, so that a death incurred _in the act_ of collecting
the final gem also didn't increment the deaths counter. Now it does.

[originally from svn r6277]

Take the Windows taskbar into account when deciding on the maximum
size of the puzzle window. This has involved some _completely
stupid_ window manipulation: in order to figure out in advance how
big I want my main window to be, I first have to _create_ the status
bar so I know how tall it is; but since I can't reparent it into my
main window after I've created it, I then have to throw that status
bar away and create a new one. *sigh*

[originally from svn r6276]

Various patches from Ben H: a fix for an outdated comment, a couple
of spurious ps_printf() arguments removed, and an error check in the
`make install' target.

[originally from svn r6275]

I've dithered a bit in the past about whether or not it's allowable
to call game_set_size() twice on the same drawstate. Finally, a
definite decision: it isn't. Accordingly, midend.c arranges never to
do so, the devel docs state that puzzles may enforce by assertion
that it never happens, and the four puzzles which care (i.e. use
blitters) do so.

[originally from svn r6274]

Patch from Ton van Overbeek to fix a small memory leak in
midend_solve().

[originally from svn r6271]

Patch from Ton van Overbeek to correct Loopy's misplaced line ends
at small tile sizes.

[originally from svn r6270]

Another global environment-variable override across all games. This
one is <game>_TILESIZE, adjusting the game's default size. I
anticipate that this will probably _mostly_ be useful for debugging.

[originally from svn r6269]

Couple of minor updates to restore accuracy.

[originally from svn r6268]

Patches from James H. The usual stuff (memory leak fixes and 16-bit
cleanliness), plus he's enlarged the pencil-mark circles from
TILESIZE/8 to TILESIZE/7. Makes no difference at all (thanks to
integer division) when TILESIZE is the default of 20, but presumably
helps at some other tile sizes. Fine by me.

[originally from svn r6265]

Someone points out that the Solo text formatter would be a lot
better if it marked empty cells with something other than a space.
So here's a three-bit change to turn it into a dot :-)

[originally from svn r6261]

Stop Light Up from eating system keypresses, which it was previously
doing whenever the cursor was active.

[originally from svn r6258]

Optimiser placation.

[originally from svn r6257]

Palm fixes for Loopy from James H: a #ifdef SLOW_SYSTEM, and an
int/long fix.

[originally from svn r6256]

James H's memory leak fixes to Inertia.

[originally from svn r6255]

James H has implemented a new `Tricky' difficulty level in Light Up:
a non-recursive level above Easy, which therefore moves the
recursive Hard mode further up still. Play-testing suggests that in
fact Tricky is often _harder_ than the old Hard mode, since the
latter had limited depth of recursion and would therefore spot
complex deductions only if it happened to start a recursion on the
right square; Tricky may be limited in the sophistication of its
complex deductions, but it never misses one, so its puzzles tend to
be hard all over.

Also in this checkin, a new source file `nullfe.c', containing all
the annoying stub functions required to make command-line solvers
link successfully. James wrote this for (the new) lightupsolver, and
I've used it to simplify the other stand-alone solvers.

[originally from svn r6254]

Ability to drag pencil marks around.

[originally from svn r6250]

Terribly cunning approach to making the pencil marks look nicer,
thanks to Gareth.

[originally from svn r6248]

Debian requires -lm, where Red Hat didn't.

[originally from svn r6247]

Ahem; forgot about recursion. Recursive solving now shows its
working as well.

[originally from svn r6245]

Now that Map has some seriously complex deductions, it's about time
it had a command-line solver. In order to do this, I've had to
expose the internal region numbering because the solver has to have
some way to state which region it means; and in any case it's also
useful to have human-visible region numbering so that two people can
discuss a puzzle they're solving together. So pressing L during play
now toggles the display of region numbers; and `mapsolver' uses
those same numbers when showing its working and its solutions.

[originally from svn r6244]

Forcing chains in Map give rise to a new `Hard' difficulty level.
Also implemented the Map analogue of Solo's pencil marks, to make
this mode more playable.

[originally from svn r6240]

Implemented a couple more reasoning modes for Extreme difficulty
level: positional set elimination (which is so obvious I really
should have thought of it myself, though it's tricky to spot) and
forcing chains (which are a type of one-level proof by
contradiction, findable through a simple breadth-first search
without requiring recursion, but so ludicrously powerful that they
are able to solve _two thirds_ of grids that the pre-Extreme Solo
generated and rated as Unreasonable).

Of course this makes Unreasonable mode harder still...

[originally from svn r6239]

Backspace and Delete keys now function like Space in Solo.

[originally from svn r6237]

Typo in comment :-)

[originally from svn r6236]

Ahem. The region density at which things start to get hairy is 2/3
of the grid area, not 3/2!

[originally from svn r6235]

Aesthetic improvements to the Map error indicators:
 - the exclamation mark was a bit dot-heavy
 - allowing the indicator to be placed at a grid point as well as
   half way between two grid points allows some much more natural
   positioning.

[originally from svn r6234]

Unreasonable mode for Map.

[originally from svn r6229]

Error highlighting in Map.

[originally from svn r6228]

There seems to be some odd behaviour when GTK is asked to draw an
outline polygon with a clipping rectangle active. I don't know or
care whether this is GTK or my X server or what, but I'm working
around it by drawing the lines myself, which seems to sort it out.

[originally from svn r6227]

HACKING.but -> devel.but

[originally from svn r6226]

Fix array bounds violation in the solver. Oops.

[originally from svn r6225]

OS X seems particularly picky about possibly uninitialised
variables. Placate its optimiser (again).

[originally from svn r6223]

New puzzle: `Inertia', originally written for Windows by Ben
Olmstead and reimplemented with the help of his source code which he
was kind enough to release into the public domain.

[originally from svn r6222]

Trivial doc changes after recent prolificacy.

[originally from svn r6220]

Memory leak and type safety fixes from James H.

[originally from svn r6219]

Phil Bordelon points out that the general convention is to orient
rectangular presets in a portrait fashion.

[originally from svn r6217]

Mike points out that I made an error in one of the presets...

[originally from svn r6216]

Over-enthusiastic assertion introduced in the printing revamp was
causing Mines to crash one second after starting a game. Oops.

[originally from svn r6214]

Optimiser placation for OS X gcc.

[originally from svn r6212]

New puzzle: `Loopy', an implementation of Nikoli's `Slither Link' or
`Loop the Loop' puzzle. Contributed by Mike Pinna.

[originally from svn r6211]

Minor update to Solo's documentation due to Extreme mode.

[originally from svn r6210]

Brand new difficulty level in Solo. The other day Gareth and I
independently discovered an advanced reasoning technique in Map, and
then it occurred to me that since Solo can also be considered as a
graph-colouring game the same technique ought to be applicable. And
it is; so here's a new difficulty level, `Extreme', which sits just
above Advanced. Grids graded `Extreme' by new-Solo will of course
fall into old-Solo's `Unreasonable' category (since they're not
soluble using the old set of non-recursive methods). A brief and
unscientific experiment suggests that about one in six Unreasonable
grids generated by old-Solo are classified Extreme by the new
solver; so the remaining Unreasonable mode (now containing a subset
of the grids it used to) hasn't actually become much harder.

[originally from svn r6209]

Don't report an error when loading a saved game from the command
line unless there really _is_ an error!

[originally from svn r6203]

James H points out a rogue fprintf in Net's print routine.

[originally from svn r6202]

Memory leak in the new printing stuff, plus a couple of comment
corrections.

[originally from svn r6199]