works, but it's slow, and the puzzles are currently at a relatively
low level of difficulty. Also this is a generator only: no UI yet
(because I'm waiting to see if I can make the generator practical
before bothering to write the rest).
[originally from svn r7700]
arbitrary unclaimed square. This cures the most common cause of
generation failures (covering a large area in dominoes was the most
difficult case, and would fail even if the large area was 1xn!); the
failure rate is now sufficiently low under all circumstances I've
found that I'm willing to just loop until I get a success.
[originally from svn r7693]
rectangle into equally sized ominoes. I have a couple of potential
applications for this, but none I've actually implemented yet, so
for the moment it's living in `unfinished'.
[originally from svn r7690]
suppress the display of `this square can't be a light' blobs in a
lit square, on the grounds that we already know _lit_ squares can't
be lights. This makes the solved game look cleaner (I've always
thought the detritus of blobs on some but not all non-light squares
looked messy), but on the other hand it's slightly jarring during
play. So I'm checking it in, but as a configurable option which is
off by default.
[originally from svn r7656]
`clues' array being able to be -1, so we must explicitly declare it
as `signed char' or it will break on platforms whose default char is
unsigned.
[originally from svn r7636]
about eating the letter `d' (for `diagonal') when it appears in a
symmtery description: it should only be used after `m', because
mirror symmetry is the only type that can be diagonal. This was
causing parsing of the parameter description `3x3adu' to produce the
wrong answer: the d would be swallowed, then the u ignored for being
incomprehensible, and you'd get default Trivial difficulty.
[originally from svn r7386]
across changes in game parameters (e.g., changing difficulty without changing
size). This also has the effect of preserving the user-selected tilesize if the
grid size is changed. (From Debian bug#379452.)
[originally from svn r7368]
(from Debian bug#379452).
Tested on Gtk 2. I've been unable to find a Gtk+-1.2 installation on which
Puzzles compiles, so not tested there.
[originally from svn r7367]
amount of code. James has ripped out the solver's version of
check_complete(), in favour of using the one I wrote for the
game-playing UI. My one checks connectedness, which means that the
solver will now not believe non-solutions to puzzles where
connectedness becomes a difficult issue. Examples of game IDs which
are now solved correctly but were previously not are 5x3:ubb and
7x7:ajfzmfqgtdzgt.
[originally from svn r7362]
binary from the Galaxies source file. The function of the new
`galaxiespicture' is to take a .xbm bitmap on standard input and
convert it into a Galaxies game ID using both black and white dots,
such that when solved the puzzle displays the input bitmap.
In the process of this I've implemented a post-processing pass after
the main game generation, to prevent clusters of adjacent
singletons. James H already solved that problem for unconstrained
game generation, but for some reason it came back when I did this.
However, the post-processing pass is still turned off for normal
usage, on the basis that (a) if it ain't broke don't fix it, and (b)
it's rather slow and best avoided if not necessary.
[originally from svn r7354]
you've got your source code from a tarball (with makefiles) or from
svn (without makefiles). While I'm here, mention Makefile.wce.
[originally from svn r7352]
- missing static in filling.c
- better robustness in execute_move() in filling.c
- remove side effects in assert statements
- remove rogue diagnostic in galaxies.c
- remove // comment in map.c
- add more stylus-friendly UI to Pattern
- bias Unequal towards generating inequality clues rather than numeric
[originally from svn r7344]
