James H's Palm-compatibility updates to the latest Loopy changes,
working around bugs in the Palm compiler and removing Palm-
incompatible diagnostics such as fprintf.

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

Mike's changes to dsf.c alter the internal storage format of dsf
structures, meaning that ad-hoc initialisation now doesn't work.
Hence, this checkin converts all ad-hoc dsf initialisations into
calls to dsf_init() or snew_dsf(). At least, I _hope_ I've caught
all of them.

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

Minimal (i.e., lame) update to Loopy documentation to match reality -- it's
been wrong since r6299.

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

I'm sick and tired of having unfinished puzzle code lying around on
several different systems in strange directories. So I'm creating an
`unfinished' directory within source control, and centralising all
my half-finished, half-baked or otherwise half-arsed puzzle
implementations into it. Herewith Sokoban (playable but rubbish
generation), Pearl (Masyu - rubbish generation and nothing else),
Path (Number Link - rubbish generation and nothing else) and NumGame
(the Countdown numbers game - currently just a solver and not even a
generator yet).

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

r6880 accidentally backed out r6780. That's what I get for accepting
source files from Mike rather than patches, and not adequately
checking the result...

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

Add HTML documentation to the ignore list.

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

Mike Pinna has done some major reworking of the Loopy solver, giving
rise to a new Hard difficulty level.

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

Couple of minor errors.

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

Forgot to put the new .R files into makedist.sh. Oops!

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

Jesse W points out that I forgot to update the OS X front end in
r6420, so both drawing.c _and_ the front end were prepending the
time to the front of the Mines status bar, leading to a double
timestamp.

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

Always something. Mention `svn add'ing the .R file in the new-puzzle
checklist, and mention the now-not-version-controlled list.c in
svn:ignore.

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

I'm sick of repeatedly adding and removing local changes to Recipe
when testing a new game, so here's a new architecture for the Recipe
file. mkfiles.pl now supports several new features:

 - an `!include' directive, which accepts wildcards
 - += to append to an existing object group definition
 - the ability to divert output to an arbitrary file.

So now each puzzle has a `.R' file containing a fragment of Recipe
code describing that puzzle, and the central Recipe does `!include
*.R' to construct the Makefiles. That way, I can keep as many
experimental half-finished puzzles lying around my working directory
as I like, and I won't have to keep reverting Recipe when I check in
any other changes.

As part of this change, list.c is no longer a version-controlled
file; it's now constructed by mkfiles.pl, so that it too can take
advantage of this mechanism.

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

Extra utility function.

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

Random docs cleanups I've collected together.

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

Since r6711, puzzles built with Gtk 1.2 would take double actions when a menu
accelerator key (N/U/R/Q) was pressed -- once for the menu accelerator, and
once more in key_event().
This workaround, while unlovely, should at least not break in future (since the
things it relies on are unlikely to change).

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

Trivial patch from Ben Hutchings to support resizable windows under
GTK. All the infrastructure in the midend and beyond was already
there; it was just a matter of enabling it!

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

Ben Hutchings's patch to add display of key accelerators in the Game
menu.

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

Patch from Ben Hutchings to prevent an ugly special case in
&splitline in which a line is `split' into a line ending in a
backslash followed by a completely blank line.

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

Cleanup patch from Ben Hutchings, fixing some odd-looking range
checks. He thinks they were harmless (due to being followed by other
range checks in RIGHTOF_DOT and friends) but it clearly can't hurt
to fix them anyway.

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

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

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

Tidy up comments.

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

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

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

"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.

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

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.

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

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.

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

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

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

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

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

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.

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

It's a new year.

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

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

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

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

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

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.

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

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.

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

Correct w/h mixup in grid edge checks.

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

Document Unix command-line options.

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

Fix segfault in Tents' printing.

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

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

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

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

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

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.

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

Forgot to update devel.but in r6417.

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

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.

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

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

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

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.

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

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'.

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

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

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

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

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

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

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

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.

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

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

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

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

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

Small error in solver diagnostics.

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

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.

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

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! :-)

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

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

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

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.

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

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.

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

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.

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

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.

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

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.

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

Fix very strange indentation issue!

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

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

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

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.

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

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

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

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

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

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

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

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.

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

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.

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

Minor improvement to initial loop generation.

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

Oops; left some rogue diagnostics in.

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

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.

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

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

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

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

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

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.

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

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

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

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.

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

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*

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

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.

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

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.

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

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

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

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

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

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.

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

Couple of minor updates to restore accuracy.

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

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.

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

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 :-)

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

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

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

Optimiser placation.

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

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

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

James H's memory leak fixes to Inertia.

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

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.

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

Ability to drag pencil marks around.

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

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

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

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

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

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

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

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.

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

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.

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

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

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

Backspace and Delete keys now function like Space in Solo.

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

Typo in comment :-)

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

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

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

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.

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