of 'h' and 'm' are treated as digits if a square is selected, and
only treated as special commands otherwise. This renders very large
games (just about) playable.
Idea from Ben Hutchings's collection of Debian patches, although I
had to redo his (trivial) patch myself since the code has changed
recently.
(Addendum after committing: hmm, I see Jacob already applied the
original version of the patch a while back. Looks as if the recent
keyboard control change reintroduced the problem. Still, re-fixed
now.)
[originally from svn r8433]
using PANGO_CHECK_VERSION. (Irritatingly, the latter is not
available in all versions of Pango, so we have to be cautious about
using it at all. *sigh*)
[originally from svn r8430]
and also updates the docs for both that and the Mines cursor support
in r8402.
[originally from svn r8408]
[r8402 == f20847354cb6335fd349204f16021a72e2956cce]
people have generally seemed to think Loopy is one of the more
difficult puzzles in the collection. There's a new level called
Tricky, between Normal and Hard, which is equivalent to the old
Normal.
[originally from svn r8398]
doesn't have diagnostics embedded and the ASCII formatter can't
print non-square puzzles anyway; but it can grade difficulty, which
is what I most immediately want it for.
[originally from svn r8397]
alongside the individual puzzle binaries, on Windows only. (MacOS
already has it, of course; Unix would require about as much work
again.)
[originally from svn r8396]
list of selection targets offered by GTK Puzzles grows an extra copy
of each of the three supported text formats every time the user
makes a selection!
[originally from svn r8365]
function. Useful in conjunction with the new --save option to
generate lots of games, extract the aux strings from the game
generator, and de-obfuscate them in order to measure statistical
properties of their solutions.
[originally from svn r8352]
generate a thousand saved-game files of randomly generated puzzles.
On the general principle that if I find it useful someone else
conceivably might too, add a --save option to the Unix puzzle
binaries, for use with --generate in much the same way as --print.
[originally from svn r8351]
CURSOR_SELECT2 button (to, respectively, toggle a "definitely not
light" dot and to rotate in the opposite direction from
CURSOR_SELECT).
[originally from svn r8299]
a game which comes with an aux string, we immediately self-test that
string by passing it to solve() and test by assertion that it
succeeded. So a bug in a back end which intermittently generates
malformed aux strings will be detected as soon as it occurs, instead
of only if the user happens to use the Solve operation on a
particular game in which it happened.
Secondly, Ctrl-S now (undocumentedly) triggers the Solve operation,
on the general principle that keyboard shortcuts tend to come in
handy, and on the specific principle that if you want to look at
lots of solved grids in quick succession (say, when observing their
general shape and nature to see if your generation algorithm was
good or not) it's handy to have a quick way of getting to them.
[originally from svn r8298]
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]
