computers, let's save the Solo and Pattern grids at generation time
and regurgitate them when asked to solve, rather than doing all the
work over again.
[originally from svn r5737]
various things:
- if you haven't fully understood what a game is about, it gives
you an immediate example of a puzzle plus its solution so you can
understand it
- in some games it's useful to compare your solution with the real
one and see where you made a mistake
- in the rearrangement games (Fifteen, Sixteen, Twiddle) it's handy
to be able to get your hands on a pristine grid quickly so you
can practise or experiment with manoeuvres on it
- it provides a good way of debugging the games if you think you've
encountered an unsolvable grid!
[originally from svn r5731]
constructed at the same time as an internally generated game seed,
so that it can preserve any interesting information known by the
program at generation time but not physically contained within the
text of the game seed itself. (Such as, for example, the solution.)
Currently not used for anything yet, but it will be.
[originally from svn r5729]
`Cut', `Copy' and `Paste' items in the Edit menu of an OS X
application - because there's nothing else that enables the keyboard
cut/copy/paste shortcuts in an edit box! OS X Puzzles can now have
game IDs pasted into it, which it previously couldn't.
[originally from svn r5728]
as text. This is used by front ends to implement copy-to-clipboard.
Currently the function does nothing (and is disabled) in every game
except Solo, but it's a start.
[originally from svn r5724]
definitions, so let's move it so that it's just next to the
functions it relates to. This also opens the way for me to add more
booleans next to other functions without getting confused as to
which is which.
[originally from svn r5723]
introduce a sensible game ID notation for orientable games, and
finally (*blush*) turn the orientability triangles back the right
way up.
[originally from svn r5718]
puzzle, to make it construcct puzzle IDs and output them on stdout.
Also checked in print.py, a script which reads puzzle IDs on stdin
and produces PostScript output. With these, you can generate pages
of Pattern, Rectangles and Solo puzzles to take on trains with you.
[originally from svn r5707]
builds better:
- the GTK makefile now defines $(GTK_CONFIG) which you can
override, so you can build for GTK 2 with no makefile-editing
simply by running `make GTK_CONFIG="pkg_config gtk+-2.0"'
- we use Pango to find appropriate fonts, which means the text in
the puzzles actually (gasp!) adapts its size to the
circumstances. Unfortunately, I've been unable to do this
portably without depending on _either_ a Pango function that
isn't present in older versions _or_ the underlying window system
being X11; I'd appreciate someone doing better.
[originally from svn r5693]
enable configurable puzzle difficulty. I'm only generating grids up
to Times level (complicated non-recursive analysis but guessing
never required); I wouldn't object to providing a Telegraph
difficulty level (guessing required) but it turns out to be very
hard indeed to generate at random. I might still add it later
(probably under the name `Unreasonable' :-) if I can think of an
efficient way to find them.
[originally from svn r5682]
- added a compilation option -DSTANDALONE_SOLVER which makes both
of Solo's internal solvers accessible from the command line.
- fix a bug in nsolve turned up by testing in this mode: it failed
to iterate at all! Oddly, this massive improvement to the
effectiveness of nsolve hasn't emptied the generated grids by
very much.
- add an extra mode of reasoning to my to-do list (which is the
dual of one already there, so I'm kicking myself).
[originally from svn r5670]
the default symmetry from order-4 down to order-2, which seems to
mitigate the excessively-full-grid problem by permitting more
freedom to remove stuff.
[originally from svn r5666]
clipping policy work properly. I haven't proved why it didn't work
the previous way, but I have a good guess: I think that clip regions
are handled by reference. So I saved the old clip region out of the
DC, then did an IntersectClipRect, and then selected the old clip
region back in again - but the old clip region had never been
_de_-selected, because IntersectClipRect didn't change which object
was selected but rather it modified-in-place the one that already
was selected. So my attempt to restore the old clip region did
nothing whatsoever, and thus clipping to two different rectangles
during the same draw sequence failed. Now I'm completely destroying
the clip region during unclip(), which seems to work better.
[originally from svn r5662]
column of the same colour (at least when the dimensions are big
enough to make this feasible). It's a little bit too easy otherwise!
[originally from svn r5391]
width; if allowed to resize to the text within them, they look
terribly silly when containing an entire Rectangles or Pattern game
ID.
[originally from svn r5210]
back ends can be assured of always receiving them in a sensible
sequence (button-down, followed by zero or more drags, followed by
button-up, and never changing button in the middle of such a
sequence). I have a suspicion this issue was the cause of the
mysterious Pattern grid updates seen by Dan during testing last
night.
[originally from svn r5208]
out of the tarball by makedist.sh, causing the downloaded source
tree to fail mkfiles.pl. Worse still, the GTK Makefile wasn't
included, so people _needed_ to run mkfiles.pl! Both now fixed, I
think.
[originally from svn r5205]
