Memory leak fixes from James H.

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

New puzzle: `Map'. Vaguely original, for a change.

(This puzzle is theoretically printable, but I haven't added it in
print.py since there's rather a lot of painful processing required
to get from the game ID to the puzzle's visual appearance. It
probably won't become printable unless I get round to implementing a
more integrated printing architecture.)

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

Oops. Back out a local change I shouldn't have committed in r6184.

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

16-bit-cleanness fixes from James H (again). It would be really nice
to have some means of automatically spotting this sort of problem on
a desktop platform, but I can't immediately think of one; building a
trick compiler which thinks `int' is 16 bits would be the obvious
option, but it would immediately break the ABIs to all the system
functions.

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

Very fiddly corrections to the loop highlighting. ERRSLASH means the
slash in this square is red, so it does indeed imply that some of
the edge markings are also red; but it doesn't mean _all_ the edge
markings must be red. So instead of assuming ERRSLASH implies all
edge error markers, we set the correct set of edge error markers at
the same time as setting ERRSLASH, at which point we know which kind
of slash it is so we know which ones to set.

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

Implement error checking in Slant. Clue points are now highlighted
in red if it's impossible to fulfill them (either through too many
neighbours connecting to them, or too many not connecting to them),
and edges are highlighted in red if they form part of a loop.

In order to do this I've had to revamp the redraw function
considerably. Each square is now drawn including its top and left
grid edges, but _not_ its bottom or right ones - which means that I
need to draw an extra strip of empty squares outside the actual grid
in order to draw the few pixels which appear on the grid bottom and
right borders and also to red-highlight border clues.

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

Remove conditional definition of MAX_GRIDGEN_TRIES, for consistency
between Palm and other ports when fed the same random seed.

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

Placate optimiser.

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

Streamline `slantsolver' a bit (avoid showing advanced working on
easy puzzles, and stop having a second encoding of the difficulty
levels).

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

Document hard mode in Slant, and also fix an obvious memory
management error in game_configure().

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

Introduce an environment variable setting (SLANT_SWAP_BUTTONS=yes)
to reverse the effect of the mouse buttons. Gareth has been
complaining about this for days: apparently he finds precisely the
opposite control system intuitive to me.

This is a horrendous hack, and pushes me one step closer to losing
my temper and designing a proper preferences architecture.

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

A bunch of new reasoning techniques in the Slant solver, leading to
a new Hard mode. Also added a command-line `slantsolver' which can
grade puzzles and show working.

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

Cleanups to completion flashes: all four of these games used to
redraw the whole window _every_ time game_redraw() was called during
a flash. Now they only redraw the whole window every time the
background colour actually changes. Thanks to James H for much of
the work.

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

New puzzle: `Light Up', by James H.

Also in this checkin (committed by mistake - I meant to do it
separately), a behind-the-scenes change to Slant to colour the two
non-touching classes of diagonals in different colours. Both colours
are set to black by default, but configuration by way of
SLANT_COLOUR_* can distinguish them if you want.

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

Environment-based configuration wasn't sensibly usable in games with
spaces in the name. Fixed. (One day I really must get round to
turning this into a proper config mechanism.)

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

Patch from James H: tinker with the presets on SLOW_SYSTEMs.

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

Bug fix from James H: solve_game() was returning error messages in
the return value rather than in *error. In the old days type-
checking would have caught this, but now of course they're the same
type.

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

I am COMPLETELY GORMLESS. The Solo grid generator, when eliminating
clues from a filled grid, was using the algorithm

 - loop over the whole grid looking for a clue (or symmetry group of
   clues) which can be safely removed
 - remove it
 - loop over the whole grid again, and so on.

This was due to my vague feeling that removing one clue might affect
whether another can be removed. Of course this can happen - two
clues can be alternative ways of deducing the same vital fact so
that removing one makes the other necessary - but what _can't_
happen is for removing one clue to make another _become_ removable,
since you can only do that by _adding_ information. In other words,
after testing a clue and determining that it can't be removed, you
never need to test it again. Thus, a much simpler algorithm is

 - loop over the possible clues (or symmetry groups) _once_, in a
   random order
 - for each clue (group), if it is removable, remove it.

This still guarantees to leave the grid in a state where no further
clues can be removed, but it greatly cuts down puzzle generation
time and also simplifies the code. I am a fool for not having
spotted this in three and a half months!

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

Cleanups from James H: a few missing statics, a precautionary cast
or two, a debugging fix, a couple of explicit initialisations of
variables that were previously read uninitialised, and a fix for a
whopping great big memory leak in Slant owing to me having
completely forgotten to write free_game().

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

Slant uses the same generation strategy as Solo, despite not having
the property which devel.but claimed to be the reason why that
strategy works. A bit of thought revealed what the _real_ reason is
why this strategy works in some puzzles and not others, so I've
rewritten the paragraph to be more accurate.

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

Bah! There's _always_ one. Display glitch corrected.

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

New puzzle: `Slant', picked from the Japanese-language section of
nikoli.co.jp (which has quite a few puzzles that they don't seem to
have bothered to translate into English).

Minor structural change: the disjoint set forest code used in the
Net solver has come in handy again, so I've moved it out into its
own module dsf.c.

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

Various cleanups and clarifications to devel.but; some from Richard
B and some from me. Also an additional utility function
`random_copy' from Richard B, which he says is useful in a new
puzzle he's working on and which seems likely to come in handy again
at some point.

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

New end-game approach to Black Box. Instead of revealing the ball
positions immediately when you make an error, the game now reveals
as little information as is necessary to prove you wrong (including
none - if an existing laser path you know about is inconsistent with
your guesses, the game will just point it out and tell you nothing
new!) and you can try again. Errors are counted in much the same way
as deaths in Mines.

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

missing `i' in `\e'

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

One more fix from Ben H. Also switched round the arena colour
selection in the redraw function, so that locked squares are no
longer displayed once the game is at an end. (It looked untidy and
disorienting for lighter-coloured locked squares to suddenly become
darker when the box was opened. You can still flip back and forth to
your previous game state using undo/redo if you want to compare the
results against your lock pattern.)

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

Various fixes and cleanups suggested by Ben Hutchings:
 - clarified wording of messages in validate_params(), including in
   particular a correction from `< 255' to `<= 255'
 - fixed random_upto() in game generation which caused the maximum
   number of balls never to be used when there was uncertainty
 - fixed widespread miscalculation of rectangular-array indices
   (multiplication by h instead of w, which would have broken
   non-square grids rather profoundly)
 - corrected an ANSI namespace violation
 - removed real functionality from the inside of assert()
   statements, so that the game should still work when compiled
   -DNDEBUG
 - couple of unnecessary linear-time loops removed.

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

Ben Hutchings reports that gcc 4 gives an optimiser warning because
it can't tell that one branch of a particular switch is always
taken. Adding a default clause with an automatic assertion failure
apparently fixes it.

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

Patches from Ben Hutchings to fix failures of sscanf error checking.

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

Tweak a paragraph after discussion with Simon.

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

Shiny new developer documentation to replace the old sketchy HACKING
guide.

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

The very core of cross() is capable of suffering integer overflow on
large puzzles. Resort to hand-hacked 64-bit arithmetic for doing dot
products; everything else remains in `long' for the moment.

(Ideally I'd auto-detect the presence of `long long' and use it in
place of my cheap plastic imitation where possible, but since I
currently don't have a configure mechanism that'll have to wait.)

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

Another diagnostic mode for Untangle: if compiled with
`-DSHOW_CROSSINGS', it will show each edge in red if it is crossed
by anything, and in black otherwise. Distracting and not
particularly useful during play, but occasionally handy for
debugging cross().

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

(GTK only so far) Allow the argument passed to a game binary to be
either a game ID or a save file name. (The former takes priority,
because you can usually find a synonym for the latter, such as by
prepending `./' or `$PWD/'.)

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

Solve animation (currently only in Untangle) was failing to set
me->anim_pos to zero, meaning that if it happened immediately after
a completion flash then anim_pos would start off half way through
its run.

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

The `Solve' operation now rotates and/or reflects the solution grid
to bring it as close as possible to the current game state. This
means that if you request `Solve' after solving a puzzle yourself,
with the intention of finding out how similar your solution is to
the program's, then you will mostly see the differences in _shape_
rather than those being masked by the fact that yours happened to be
the other way up.

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

James H profiled the new Same Game grid generator and discovered it
was spending 60% of its time in shuffle(). The purpose of the
shuffle() call was to go through a largish array in random order
until we found an element that worked, so there's no actual need to
shuffle the whole array every time and I only did it out of
laziness. So I now pick a random element each time I go round the
loop, meaning I save a lot of shuffling effort whenever the loop
terminates early (which is often). I get about a factor of two speed
improvement from this small change.

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

Until now, Same Game has been the only puzzle in this collection
which is unable to guarantee that every grid it generates can be
solved. So I'm eliminating that exception: this checkin contains a
more sophisticated grid generator which does guarantee solubility.
It's a bit slow (most noticeably on the 15x10c3 preset), and the
quality of the generated grids is slightly weird (a tendency toward
small regions rather than large sweeping areas of contiguous
colour); however, I'm willing to see the latter as a feature for
now, since making the game more challenging while simultaneously
guaranteeing it to be possible sounds like an all-round win to me.

From now on I'm raising my standards for contributions to this
collection. I made this fix to Same Game because I heard a user
_automatically assume_ that any puzzle in my collection would not be
so uncouth as to generate an impossible grid; as of this checkin
that's actually true, and I intend to maintain that standard of
quality henceforth.

(Guaranteeing a _unique_ solution is more of an optional extra,
since there are many games for which it isn't a meaningful concept
or isn't particularly desirable. Which is not to say that _some_
games wouldn't be of unacceptably low quality if they failed to
guarantee uniqueness; it depends on the game.)

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

I've been meaning to do this for ages: all the Makefiles now give
$(XFLAGS) _after_ $(CFLAGS) on the compiler command lines, meaning
that you can provide options in XFLAGS on the makefile which will
override the ones in CFLAGS. For example, `make XFLAGS=-O0' to make
debugging easier.

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

Sync with website

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

The Untangle completion flash was weedy and anaemic; beef it up a
bit. In particular, it now flashes between _two_ specially picked
colours (white and mid-grey), meaning that it should be visible even
if your default background colour is white; and it also flashes
twice rather than once.

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

Some attempt to explain Dominosa for those unfamiliar with dominos. (Not sure
I've succeeded.)

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

Another fix from Chris: Guess's allow-blanks mode wasn't allowing
blanks...

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

Fix to Chris's patch in r6106 (also from Chris).

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

Switch Untangle to using `long' rather than `int' in its internal
rationals, for the sake of 16-bit-int platforms such as Palm. Thanks
to James H.

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

Quite a few instances of the Cardinal Error of Ctype were turned up
by a grep I just did. Oops.

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

Two tiny cleanup patches from James H.

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

Get rid of the malloc in shuffle(), by defining a subfunction
memswap() which declares a fixed-size buffer on the stack and uses
it multiple times if necessary.

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

Patch from Chris Emerson: rather than dynamically calling
get_correct() at (among other things) every redraw, we call it once
at the creation of a new game_state to save CPU.

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

Black Box: fix "reveal" button location, explain what's meant by the
`firing range'

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

Use \q{} and \by in Black Box docs.

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

I keep forgetting to do things when adding a new puzzle, so here's a
checklist.

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

Bah, there's always one: failed to `svn add' blackbox.c itself!

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

Another game from James H: `Black Box'.

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

Cleanups and memory leak fixes from James H.

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

Sanity-checking patch from Phil Bordelon: since Solo can't cope with
more than 36 distinct symbols (it runs out of alphanumerics), check
this in validate_params. I hate to do this, since I like puzzle
sizes to at least be open-ended in _principle_, but in this case
there's a fundamental UI limitation which won't be fixed by getting
a faster CPU.

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

New puzzle: `Untangle', cloned (with the addition of random grid
generation) from a simple but rather fun Flash game I saw this
morning.

Small infrastructure change for this puzzle: while most game
backends find the midend's assumption that Solve moves are never
animated to be a convenience absolving them of having to handle the
special case themselves, this one actually needs Solve to be
animated. Rather than break that convenience for the other puzzles,
I've introduced a flag bit (which I've shoved in mouse_priorities
for the moment, shamefully without changing its name).

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

Improve speed of grid generation: I've found something simple I can
do during construction which massively increases (by over a factor
of four with default parameters) the probability that any given
randomly generated grid will be uniquely solvable.

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

Add Dominosa printout support.

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

Cleanups to Solo:
 - use the new `shuffle' utility function in a couple of places
 - remove the random_state parameter from solver(). It was there
   because I initially wanted to use the same solver for grid
   generation, but since I had to abandon that plan the solver now
   doesn't have any need for randomness at all.

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

New puzzle: Dominosa.

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

Introduce a `shuffle' utility function.

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

game_timing_state() now has access to the game_ui. This means that
whether the timer is currently going is no longer solely dependent
on the current game_state: it can be dependent on more persistent
information stored in the game_ui. In particular, Mines now freezes
the timer permanently once you complete a grid for the first time,
so that you can then backtrack through your solution process without
destroying the information about how long it took you the first time
through.

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

Change of policy on game_changed_state(). Originally, it was called
by the midend every time the game state changed _other_ than as a
result of make_move(), on the basis that when the game state changed
due to make_move() the game backend had probably noticed anyway.
However, when make_move() split up, this became more fiddly: if the
game_ui had to be updated based on some property of the final game
state, then execute_move() couldn't do it because it didn't have a
pointer to the game_ui, but it was fiddly to do it in
interpret_move() because that didn't directly have a copy of the
finished game state to examine. Same Game (the only game to be
affected) had to deal with this by actually having interpret_move()
_call_ execute_move() to construct a temporary new game state,
update the UI, and then throw it away.

So now, game_changed_state() is called _every_ time the current game
state changes, which means that if anything needs doing to the
game_ui as a result of examining the new game state, it can be done
there and save a lot of effort.

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

Subtle UI change to Mines. Although I mostly find the unified left-
button interface (same button to open a closed square or to clear
around an open one) to be a massive help, there is one circumstance
in which it frequently kills me: if I click down on an open square I
want to clear around, then the mouse pointer accidentally drifts
over on to the nearest closed square before I release, I'll end up
opening that square instead and (usually) dying. So this checkin
causes Mines to note which type of square I left-clicked on, and to
do nothing if the button release is on the other type.

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

Alter the `Octagon' board preset so that instead of presenting you
with the obvious central hole it presents you with a randomly chosen
one of twelve other holes. The reason is, the central-hole starting
position is provably insoluble (proof given in comments), so instead
we pick from the ones that are actually possible.

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

Missing quit on error was leading to an assertion failure on some
types of incorrectly formatted save file.

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

Move various printf()s after declarations.

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

Unify the two solvers in Solo. nsolve has now had recursion
capability added to it, to be used only when all else fails, and is
simply called `solver'. This means that:

 - solving of 5x5 Trivial grids using the `Solve' function, which
   previously hung for ages because rsolve happened to take a wrong
   turning at the start, is now zippy
 - solosolver doesn't require the confusing -r and -n options
 - solosolver can show its working even for Unreasonable grids.

Unfortunately, the new unified solver still isn't suitable for grid
generation. After it proved to be so much faster at solving 5x5s, I
hoped to be able to substitute it for rsolve during generation and
gain additional speed in 5x5 generation too; but no luck, because
it's slower _per recursion level_, and although during solving it
makes up for this by needing very few levels, there is a lot of
_unavoidable_ recursion during generation, especially at 5x5. A
hybrid strategy which starts off with rsolve and switches to the
unified solver at a critical point proved unsatisfactory as well,
because the critical point changes depending on the vagaries of the
recursion and can't be pinpointed easily. So rsolve is still in
there, only renamed `gridgen' because that's now all it's good for.

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

Refactoring from James H: the highlight and lowlight colour setup
common to Fifteen, Sixteen, Twiddle and Pegs is now a utility
function in misc.c.

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

Some patches from James H:
 - reinstate the initialisation of ds->w and ds->h in guess.c, which
   I'd accidentally removed during game_size() refactoring
 - reorganise Net's interpret_move() so that my uncommitted patch
   for drag-based UI (which he uses on the Palm port) will apply
   more easily
 - the interpret_move() changes make it easy to have a single move
   type which rotates a tile by 180 degrees, so this is now provided
   via the `F' key (but there's no spare button available to provide
   it via the mouse).

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

Revert the code that assumed that incoming parameters used a random generation
scheme in r6068, since this messed up the non-permanency of the non-limited
parameter.

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

Add a `full' parameter to validate_params(), analogous to the one in
encode_params(). This is necessary for cases where generation-time parameters
that are normally omitted from descriptive IDs can place restrictions on other
parameters; in particular, when the default value of a relevant generation-time
parameter is not the one used to generate the descriptive ID, validation could
reject self-generated IDs (e.g., Net `5x2w:56182ae7c2', and some cases in
`Pegs').

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

Enhancements to mkfiles.pl and Recipe to arrange for the auxiliary
command-line programs (solosolver, patternsolver, mineobfusc) to be
built as part of the normal Makefiles. This means mkfiles.pl now has
the capability to compile a source file more than once with
different #defines. Also, fixes for those auxiliary programs and one
fix in midend.c which the Borland compiler objected to while I was
testing its makefile generation.

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

It's been a new year for a while now.

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

revert supposed typo -- I have no brain

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

Add HACKING to main doc build.

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

typo

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

Add a completion flash when you get down to a single peg.

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

Add `pegs' to svn:ignore.

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

Refactored the game_size() interface, which was getting really
unpleasant and requiring lots of special cases to be taken care of
by every single game. The new interface exposes an integer `tile
size' or `scale' parameter to the midend and provides two much
simpler routines: one which computes the pixel window size given a
game_params and a tile size, and one which is given a tile size and
must set up a drawstate appropriately. All the rest of the
complexity is handled in the midend, mostly by binary search, so
grubby special cases only have to be dealt with once.

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

James Harvey points out a missing ifdef.

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

Clarify that diagonal moves are not permitted in Pegs.

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

Add WinHelp topic.

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

There's always one. Forgot to add Pegs to `make install'.

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

Documentation for Pegs.

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

Peg Solitaire implementation, complete with a random board
generator. The generator is lacking in almost any kind of finesse,
but it produces puzzles which at least _I_ find plausibly puzzling.

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

Document keyboard controls for Flip

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

Fix bounds checking for Flip cursor control.

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

James H's patch for a keyboard-controlled cursor in Flip.

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

Allow game backends to use even special keystrokes such as N and Q;
they will only be processed as special by the midend if unwanted by
the backend. This causes 5x5 Solo to become just about playable,
because you can now click in a square and type `n'. However, typing
`n' when a square is not selected will revert to the normal
behaviour of starting a new game.

(This isn't particularly ideal, I know, but it's better than
nothing.)

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

draw_polygon() and draw_circle() have always had a portability
constraint: because some front ends interpret `draw filled shape' to
mean `including its boundary' while others interpret it to mean `not
including its boundary' (and X seems to vacillate between the two
opinions as it moves around the shape!), you MUST NOT draw a filled
shape only. You can fill in one colour and outline in another, you
can fill or outline in the same colour, or you can just outline, but
just filling is a no-no.

This leads to a _lot_ of double calls to these functions, so I've
changed the interface. draw_circle() and draw_polygon() now each
take two colour arguments, a fill colour (which can be -1 for none)
and an outline colour (which must be valid). This should simplify
code in the game back ends, while also reducing the possibility for
coding error.

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

James Harvey points out that entering an invalid game ID can affect
the current midend state even if you don't subsequently enter a
valid one. Reorganise midend_game_id_int() so that (just like
midend_deserialise()) it does all its error checking before altering
anything in the midend's persistent data, so that it either succeeds
completely or fails before doing anything at all.

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

Prevent drags from being started outside the playing area, which was
causing invalid move descriptions to be returned from
interpret_move() and then failing an assertion when execute_move()
refused them.

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

Preset names retrieved from the environment must be dupstr()ed. How
did I miss this before? It just caused a segfault for me, which is
entirely fair enough, but I've no idea why it didn't fail before!

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

Load and Save are now supported on all three desktop platforms, and
documented. (This means the GTK temporary dependency on an
environment variable is now gone.)

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

General robustness patch from James Harvey:
 - most game_size() functions now work in doubles internally and
   round to nearest, meaning that they have less tendency to try to
   alter a size they returned happily from a previous call
 - couple of fiddly fixes (memory leaks, precautionary casts in
   printf argument lists)
 - midend_deserialise() now constructs an appropriate drawstate,
   which I can't think how I overlooked myself since I _thought_ I
   went through the entire midend structure field by field!

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

Attempting to begin a drag from (i.e. just click on) the hint pegs
for a past guess caused strangeness up to and including segfault,
thanks to bad bounds checking. Well spotted John Sullivan.

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

Add a cast whose absence was causing a (-Werror-exacerbated) compile
warning on OS X.

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

Validation of random-state-type game descriptions was broken. This
meant that a Mines game saved before the first click had taken place
could not be successfully reloaded.

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