(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]
(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]
maxflow.c. Also in this checkin, fixes to the OS X and GTK back ends
to get ALIGN_VNORMAL right. This is the first time I've used it! :-)
[originally from svn r6390]
it had a command-line solver. In order to do this, I've had to
expose the internal region numbering because the solver has to have
some way to state which region it means; and in any case it's also
useful to have human-visible region numbering so that two people can
discuss a puzzle they're solving together. So pressing L during play
now toggles the display of region numbers; and `mapsolver' uses
those same numbers when showing its working and its solutions.
[originally from svn r6244]
(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.)
[originally from svn r6186]
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.
[originally from svn r6164]
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.
[originally from svn r6155]
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.
[originally from svn r6152]
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.)
[originally from svn r6124]
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).
[originally from svn r6097]
- 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).
[originally from svn r6070]
