to resize the puzzle to zero size. Ignore all such requests, in the
assumption that a more sensible resize will be along soon enough
(which does seem to happen, though I haven't debugged the NestedVM
front end hard enough to figure out why the bogus resizes happen in
the first place).
[originally from svn r8094]
print all possible paths to a value. The latter has a lot of
de-duplication left to be done, due to multiple evaluation orders.
[originally from svn r8061]
Type menu, it looks faintly silly that Fifteen doesn't have any
presets other than Custom: you open a Fifteen window in its default
state, and the Type menu appears to be telling you it has a custom
size! Fixed by adding a preset for the default parameters.
I'd quite like to fix this properly by revamping the presets
mechanism in a way that _enforces_ that there must always be a
preset which matches the default parameters, but that's more fiddly
than it sounds. For the moment, this change fixes the only
externally visible infelicity in the current game set.
[originally from svn r7983]
currently selected preset, if any. I've used this in the GTK front
end to have the Type menu mark the currently selected menu item.
(After considerable beating of GTK with sticks, I might add. Grr.)
Currently the same UI feature is not yet supported on Windows or
MacOS, but I hope to do those too at some point if it's feasible.
[originally from svn r7980]
suggested by IWJ last night: grid generation can immediately choose
an entire grid row randomly, since all that's doing is nailing down
the names of the numbers, and that gets the whole thing started more
efficiently. But the main difference is that now grid generation is
given only area^2 steps to come up with a filled grid, and then cut
off unceremoniously, causing grid generation to fail and be retried
from scratch. This seems to prevent hangups on jigsaw layouts that
admit few useful solutions, by changing layout constantly. 9j
puzzles now generate at a sensible rate, and as an added bonus so do
5x5 normal puzzles, which they never used to.
[originally from svn r7978]
failed to point out a declaration after a statement, and gcc's
linker was clever enough to optimise the call to divvy_rectangle()
out of solosolver so that I didn't have to include divvy.c in that.)
[originally from svn r7975]
(require both main diagonals to have one of every digit in addition
to all the usual constraints) and Jigsaw Sudoku (replace the array
of rectangular sub-blocks with the sub-blocks being random
polyominoes). To implement the latter, I've moved my `divvy.c'
library routine out of the `unfinished' subdirectory.
Jigsaw mode is currently an undocumented feature: you enable it by
setting the rows parameter to 1 (and the columns parameter to your
desired grid size, which unlike normal Sudoku can be anything you
like including a prime number). The reason it's undocumented is
because generation times are not yet reliably short: sometimes
generating a jigsaw-type puzzle can hang for hours and still get
nowhere. (The algorithm should terminate in principle, but not in
any time you're prepared to wait.) I _think_ I know how to solve
this, but have yet to try it. Until then, jigsaw mode will remain a
hidden feature.
Printing of X-type puzzles is also substandard at present, because
the current print-colour API replaces the desired light shading of
the X-cells with heavy diagonal hatching. I plan to adjust the API
imminently to address this.
[originally from svn r7974]
it got rid of the bogus backgrounds on all the text; but on the
other hand it mysteriously caused all the images to become black and
white! Serves me right for testing with Bridges which was B&W to
start with. Instead, we'll just tell xvfb to use a 24-bit display
and let it sort out the visuals for itself; that seems to work better.
[originally from svn r7932]
generates PPC/Intel dual-architecture binaries.
This turns out not to be too painful: you compile and link your
programs using `gcc -arch ppc' or `gcc -arch i386', then you use a
command of the form `lipo -create ppc-binary i386-binary -output
binary' to construct a universal binary. It works equally well on
command-line standalone executable files and the executables within
application directories. Also added the -mmacosx-version-min option,
since otherwise the OS X build tools appear to default to building
binaries which will crash (without anything resembling a
comprehensible error message) on any earlier release.
The handling of version.o in this checkin is somewhat grotty. I'd
prefer a method more cleverly intertwingled with mkfiles.pl so I
didn't have to maintain the OS X architecture list in both
mkfiles.pl and Recipe. (Not that I anticipate Apple switching
architectures again in the immediate future, but it's the principle
of the thing.)
[originally from svn r7916]
(This change adds a new possibility to the save format, such that new save
files won't necessarily be loadable by old binaries. I think that's acceptable
-- it's certainly happened before -- but I couldn't find anything in the
developer docs explicitly blessing it.)
[originally from svn r7849]
connected polyominoes actually causes a loss of generality for
sufficiently large k. I hadn't previously noticed, because you need
k to be (I think) at least 23 and none of my potential applications
require anything nearly that large. Add some discussion of this.
[originally from svn r7701]
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]
