particular, Great Hexagonal tilings previously had virtually every
(if not _actually_ every) hexagon on the inside of the path, and now
don't.
[originally from svn r8277]
Unequal 18x18 or above was unplayable due to a clash with the undocumented
"H" (hint) key. Resolve the clash by making the hint function only fire
when no square is selected.
[originally from svn r8200]
spins forever, but observes that raising the limit to 4x4 across all
grid types is not good for the complex grids like great-hexagonal.
Introduce per-grid minimum sizes using mad macro trickery.
(In fact, for each grid type I've put in a minimum size which _both_
dimensions must equal or exceed, plus another minimum size which _at
least one_ must equal or exceed; that permits both 3x4 and 4x3 Cairo
while disallowing 3x3.)
[originally from svn r8191]
gameplay. Having tried methods based on using the slashes to define
a dsf on grid vertices, and also methods based on tracing round the
loops using conventional (non-dsf-based) graph theory, it occurred
to me the other day that there's a far simpler technique involving
connectivity. A loop is precisely that which causes the playing area
to become disconnected; so what we do now is to go through and build
a dsf describing connectedness of the _area_ of the grid rather than
the vertices. That divides the area into its maximal connected
components, and then we can trivially identify every edge that's
part of a loop by noticing that it separates two nonequivalent
pieces of space. The resulting algorithm is half the size of the old
one, and it's much easier to be confident of its correctness.
(Having said which, there will doubtless turn out to be an
embarrassing bug in it, but I haven't found it yet.)
[originally from svn r8187]
Ubuntu system. I'm inclined to think the real problem is in his gtk
headers, but this is a harmless enough change to avoid hassle.
[originally from svn r8181]
defining it centrally per port, I think it's neater to define it for
each puzzle when adding that puzzle to the ALL list - because those
front ends which take -DCOMBINED are precisely those which use ALL.
In particular, this change opens up the possibility of compiling
both individual puzzles _and_ a combined monolith within the same
makefile.
[originally from svn r8178]
actual behaviour change: Untangle now permits dragging with the
right mouse button, which has exactly the same effect as it does
with the left. (Harmless on desktop platforms, but helpful when
"right-click" is achieved by press-and-hold; now the drag takes
place even if you hesitate first.)
[originally from svn r8177]
on Windows at all?! Fix some departures from the C standard, mostly
declaring variables after a statement has already been issued in the
same block. MSVC is picky about this where gcc is forgiving, and TBH
I'd change the latter given the choice.
[originally from svn r8166]
Lambrou. Now capable of handling triangular and hexagonal grids as
well as square ones, and then a number of semiregular plane tilings
and duals of semiregular ones. In fact, most of the solver code
supports an _arbitrary_ planar graph (well, provided both the graph
and its dual have no self-edges), so it could easily be extended
further with only a little more effort.
[originally from svn r8162]
_conditionally_ able to format the current puzzle as text to be sent
to the clipboard. For instance, if a game were to support playing on
a square grid and on other kinds of grid such as hexagonal, then it
might reasonably feel that only the former could be sensibly
rendered in ASCII art; so it can now arrange for the "Copy" menu
item to be greyed out depending on the game_params.
To do this I've introduced a new backend function
(can_format_as_text_now()), and renamed the existing static backend
field "can_format_as_text" to "can_format_as_text_ever". The latter
will cause compile errors for anyone maintaining a third-party front
end; if any such person is reading this, I apologise to them for the
inconvenience, but I did do it deliberately so that they'd know to
update their front end.
As yet, no checked-in game actually uses this feature; all current
games can still either copy always or copy never.
[originally from svn r8161]
argv[1], which in turn feeds it into the midend as a game ID. This
can of course take any of the forms supported by the native C
puzzles: a pure game parameter string, a params:description specific
game ID, or a params#seed random game ID.
[originally from svn r8095]
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]
