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.

[originally from svn r9711]

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

[originally from svn r9694]

Remove an unused variable spotted by gcc 4.6.3.

[originally from svn r9682]

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

[originally from svn r9680]

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

[originally from svn r9660]

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

[originally from svn r9659]

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

[originally from svn r9658]
[r9657 == 3b250baa02a7332510685948bf17576c397b8ceb]

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.

[originally from svn r9657]

Minor tweaks to Undead docs.

[originally from svn r9656]

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.

[originally from svn r9652]

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.

[originally from svn r9606]

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

[originally from svn r9605]

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

[originally from svn r9594]

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

[originally from svn r9561]

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.

[originally from svn r9558]
[r9495 == d0ff371b144d4bfe3cbfb062388347c08e431393]

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!

[originally from svn r9549]

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.

[originally from svn r9548]

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.

[originally from svn r9547]

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

[originally from svn r9546]

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

[originally from svn r9544]

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

[originally from svn r9543]

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

[originally from svn r9542]

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.

[originally from svn r9534]

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.

[originally from svn r9533]

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.

[originally from svn r9505]

GNUstep compatibility: add a missing #include.

[originally from svn r9504]

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.

[originally from svn r9503]

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 separated the processButton: method into one for
mouse buttons and one for keys, since that was the easiest way to
ensure the coordinates passed to the mid-end for the latter are -1,-1
_after_ translation rather than before.

[originally from svn r9502]

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

[originally from svn r9501]

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

[originally from svn r9500]

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

[originally from svn r9499]

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.

[originally from svn r9498]

Stop using the deprecated NSString stringWithCString: methods.

[originally from svn r9495]

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.

[originally from svn r9494]

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

[originally from svn r9455]

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

[originally from svn r9454]

Typo fix from Helge Kreutzmann, forwarded from Debian.

[originally from svn r9453]

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.

[originally from svn r9452]

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

[originally from svn r9451]

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.

[originally from svn r9450]

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.

[originally from svn r9448]

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!

[originally from svn r9447]

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

[originally from svn r9446]

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.

[originally from svn r9445]

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

[originally from svn r9442]

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

[originally from svn r9411]

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.

[originally from svn r9408]

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

[originally from svn r9406]
[r9405 == 0c13787c2a17adc891f8e47c06b259f80bc8251a]

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

[originally from svn r9405]

Correct kdiff setting.

[originally from svn r9403]

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.

[originally from svn r9402]

Fix a couple of typos in messages.

[originally from svn r9401]

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

[originally from svn r9400]

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

[originally from svn r9393]

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.

[originally from svn r9392]

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.

[originally from svn r9388]

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.

[originally from svn r9387]

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.

[originally from svn r9386]

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

[originally from svn r9384]

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

[originally from svn r9382]

Tweak right-click processing to be less finicky.

[originally from svn r9381]

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

[originally from svn r9379]

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.

[originally from svn r9377]

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

[originally from svn r9375]

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

[originally from svn r9374]

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.

[originally from svn r9373]

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

[originally from svn r9372]

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.

[originally from svn r9306]

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.

[originally from svn r9305]

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.

[originally from svn r9304]

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

[originally from svn r9179]

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

[originally from svn r9175]

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.

[originally from svn r9173]

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.

[originally from svn r9170]
[r9165 == e7b2a9dd8d8915802fb69ce2242b1f913b7f3172]

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

[originally from svn r9168]

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

[originally from svn r9167]
[r9164 == 2efc77d2fde7e53604f8490b57f18a36eec5c4fb]

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.

[originally from svn r9166]

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.

[originally from svn r9165]

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

[originally from svn r9164]

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

[originally from svn r9163]

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

[originally from svn r9161]

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.

[originally from svn r9159]

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.

[originally from svn r9158]

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.

[originally from svn r9157]

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

[originally from svn r9156]

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

[originally from svn r9155]

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

[originally from svn r9154]

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

[originally from svn r9151]

Remove a stray diagnostic.

[originally from svn r9147]

Fix an amusing cut-and-paste error in the Java drawing code which was
causing complete mis-draws - but only when the window was exactly the
right size!

[originally from svn r9146]

Adjust the yellow used for LINE_UNKNOWN so that it's always a bit
darker than the background, because the Java front end demonstrates
that it's a bit eyewatering when it _matches_ the background.

[originally from svn r9145]

Trivial markup fix.

[originally from svn r9144]

Add a new deduction to Easy level, which is as small as I can make it
to have the effect of enabling large Easy-level grids to be
constructed in all grid types. Without this, some generations at Easy
level (e.g. 'loopy --generate 1 7x7t9de') can spin forever because
_even with all clues filled in_ the generated grids can't be solved at
that level.

[originally from svn r9143]

Move up midend_is_solved() in the developer docs from subheading to
heading level. It's _almost_ apt to have it as a subheading of
midend_solve(), but not quite, and it certainly wasn't intentional - I
must have absentmindedly typed the wrong Halibut command letter.

[originally from svn r9142]

Add a function to every game backend which indicates whether a game
state is in a solved position, and a midend function wrapping it.

(Or, at least, a situation in which further play is pointless. The
point is, given that game state, would it be a good idea for a front
end that does that sort of thing to proactively provide the option to
start a fresh game?)

[originally from svn r9140]

Add functions provided by the midend to tell a front end whether GUI
buttons for undo and redo should currently be greyed out.

[originally from svn r9139]

Rework the Loopy grid drawing algorithm so that it doesn't assume when
it clears a clipping region that it knows what features will need
redrawing in that region. Instead, I've moved all the clip/unclip/draw
functionality out into a game_redraw_in_rect() function which checks
_everything_ on the grid to see if it lies in the region.

As far as I can tell the effect only shows up in grid types that
aren't checked in, but it makes the code look nicer too.

(It would be nicer still to avoid the brute-force loop over the whole
grid checking it against the bounding box, particularly when we're
drawing in multiple bounding boxes. But this will do for the moment.)

[originally from svn r9138]

Improve the algorithm for figuring out where the number should be
drawn in a face: averaging the vertex positions works fine for regular
or roughly regular convex polygons, but it'll start being a pain for
odder or concave ones.

This is a kludgey brute-force algorithm; I have ideas about more
elegant ways of doing this job, but they're more fiddly, so I thought
I'd start with something that basically worked.

[originally from svn r9137]

When a lot of edges meet the same point - and, in particular, when
they meet at sharp enough angles that the thick lines overlap
noticeably outside the circle of the point - redrawing the edges in a
different order each time looks ugly. Arrange to always redraw edges
in order of colour, so that empty lines are drawn before indeterminate
lines which in turn come before filled-in lines.

[originally from svn r9136]

Another patch from Chris Moore implementing two more grid types, both
involving dodecagons.

[originally from svn r9109]