Hitori. One infrastructure change in the process: latin.c has
acquired a utility function to generate a latin rectangle rather
than a full square.
[originally from svn r8828]
introduced to mimic similar macros in solo.c, in case Solo ever
moved over to being based on the latin.c solver framework; but even
Solo has long since lost those macros, so latin.c has no need to
keep them.
[originally from svn r8827]
side: instead of locating a mouse click in whichever base grid
square contained the click location, we should check to see if a
tower protrudes on to that location from a neighbouring square. That
way, a click should reliably activate the tower that was actually
drawn under the mouse pointer.
[originally from svn r8826]
3D effect. (I only committed it without so that I could preserve a
record of how the code looked before I added it.) The 3D effect can
be disabled by setting TOWERS_2D in the environment, should anybody
seriously dislike it.
[originally from svn r8817]
immediately obvious which element of the group is the identity - at
least two elements including the identity have their rows and
columns completely blanked.
[originally from svn r8810]
you are given a partially specified Cayley table of a small finite
group, and must fill in all the missing entries using both Sudoku-
style deductions (minus the square block constraint) and the group
axioms. I've just thrown it together in about five hours by cloning-
and-hacking from Keen, as much as anything else to demonstrate that
the new latin.c interface really does make it extremely easy to
write new Latin square puzzles.
It's not really _unfinished_, as such, but it is just too esoteric
(not to mention difficult) for me to feel entirely comfortable with
adding it to the main puzzle collection. I can't bring myself to
throw it away, though, and who knows - perhaps a university maths
department might find it a useful teaching tool :-)
[originally from svn r8800]
their coordinate from 1 rather than 0, for consistency with Solo.
(My geek instincts would rather work from 0, but I've generally
found that puzzle users sending me email tend to prefer 1.)
[originally from svn r8795]
new function in the drawing API which permits the display of text
from outside basic ASCII. A fallback mechanism is provided so that
puzzles can give a list of strings they'd like to display in order
of preference and the system will return the best one it can manage;
puzzles are required to cope with ASCII-only front ends.
[originally from svn r8793]
any equivalence class is always the element with the smallest index.
This is slower (the previous behaviour, suggested by Jonas Koelker,
was to choose the new root element to maximise performance), but
still more than acceptably fast and more useful.
[originally from svn r8792]
programs having to clone the latin_solver() function and insert
their own extra deduction routines, they can now just _call_
latin_solver with enough parameters to let it fit its own deductions
into their difficulty framework and call a set of provided function
pointers to do user deductions. Modified Unequal to work in the new
world, of course.
[originally from svn r8791]
the < and > clues are replaced by bars separating every pair of
squares whose contents differ by exactly 1. Unlike standard Unequal,
which presents only a subset of the available clues, in Adjacent the
clues are _all_ present, so you can deduce from the absence of a bar
that the two numbers it would separate are _not_ consecutive.
[originally from svn r8790]
Guess, because Guess expected ^H whereas GTK generated ^?. Other
puzzles that use Backspace do it by being prepared to see either,
which seems wasteful. Now the midend normalises both into ^H, so
front ends can generate whichever they like while puzzles can
safely just look for ^H.
[originally from svn r8786]
buttons in several games if STYLUS_BASED is defined: in games where
you can set a puzzle element to 'on', 'off' or 'not yet set', when
it's hard to mimic a second mouse button, it's better to have the
one 'button' cycle between all three states rather than from 'on'
back to 'unset'.
[originally from svn r8784]
compiling gtk.c with STYLUS_BASED defined: most notably, it provides
a row of numeric 'keys' made of GTK button widgets for puzzles that
want a numeric keypad.
[originally from svn r8783]
in r8414 as a side effect of reorganisation in interpret_move().
Reinstate them.
[originally from svn r8692]
[r8414 == 54801998744a69786a49ebe0688942ae7b57525b]
