This refactors all instances of bitwise-ANDs with `~MOD_MASK'. There is
a handful of more complex instances I left unchanged (in cube.c, midend.c,
and twiddle.c), since those AND with `~MOD_MASK | MOD_NUM_KEYPAD' or
similar. I don't think it's worth writing a macro for those cases.
Also document this new macro's usage in devel.but.
The cursor keys navigate amongst the points. CURSOR_SELECT toggles dragging;
CURSOR_SELECT2 and the Tab key cycle through the points.
The cursor navigation scheme jumps to the nearest point within the quadrant
of the cursor direction; this seems to yield fairly intuitive gameplay.
Unfortunately, the "quadrant-nearest-neighbors" digraph produced by this
scheme is not necessarily fully reciprocal; that is, pressing opposite
cursor keys in sequence does not always return to the original point. There
doesn't seem to be any immediately obvious way around this.
As for connectivity (i.e. whether all points are reachable from any given
point), I could not find a counterexample, but I don't yet have a formal
proof that this is the case in general. Hence, I've added the ability to
cycle through all the points with Tab. (This will probably also be useful
in conjunction with the "Numbers" point drawing preference.)
According to
https://mail.gnome.org/archives/gtk-list/1999-August/msg00145.html
pressing Shift+Tab generates a special keyval of ISO_Left_Tab, without
a GDK_SHIFT_MASK applied. We now handle this case so that the midend
receives ('\t' | MOD_SHFT) as intended. This will be used by the
upcoming Untangle keyboard interface.
Previously, a button code of ('\t' | MOD_SHFT) from a frontend would have
the MOD_SHFT flag stripped by midend_process_key, resulting in a bare '\t'
passed to the backend. Now, this combination is allowed to pass through to
the backend. This will be used in the keyboard interface to Untangle, which
I'm about to add.
When a drag started outside the grid (or no drag has started yet),
ensure the drag state in game_ui says so and bail out accordingly.
Previously, such a drag would manipulate the tile the last valid drag
started from, if any, else segfault.
Also, allow drags that start on-grid and then go off-grid to continue
rotating.
The foosolver.exe binaries aren't delivered out of the end of
Buildscr, so there's no point wasting time on signing them. Signing is
slow in wall-clock time (you have to wait for a timestamp server), so
this should significantly reduce overall build time.
I updated Emscripten recently, to version 3.1.54. The result was that
none of the WASM puzzles run any more, because they produce a stack
trace at startup with the error message "to do setValue(i64) use
WASM_BIGINT".
I don't fully understand this. The stack trace comes via a JS wrapper
around a WASM-compiled function called __main_argc_argv, which sounds
like something in the Emscripten library startup. Somewhere in there
it goes via _js_get_date_64(), which tries to write an i64 into the
WASM memory array, which hits this abort in setValue().
Web searching for the error message turned up
https://github.com/godotengine/godot/pull/88594 which gave me the clue
that '-s WASM_BIGINT' is a command-line setting for the Emscripten
linker. And indeed, setting that makes the startup-time error go away
and the puzzles run again. But it also causes older versions of all
browsers to be unsupported, presumably on the grounds that they don't
have whatever WASM bigint feature this flag causes the code to use.
I don't really understand what's going on here. I assume
_js_get_date_64 is being called to handle a 64-bit time_t. But the
Puzzles code doesn't work with time_t at all, so this is entirely in
the Emscripten standard library. And if the pre-main() startup code
needs a 64-bit integer write, which won't work without this flag, then
surely _nothing_ would work without this flag, and surely someone
would have noticed that, and made that flag the default? This all
seems confusing and I wonder if I've misunderstood something.
However, if I don't fix it in _some_ way, the web puzzles will stay
out of action for days and I'll get lots of email complaints. So
here's something that makes them basically work again, and maybe we
can figure out the rest of the story later.
This includes the textual version number in its existing
form (yyyymmdd followed by an abbreviated git hash). The four-part
binary version is set to 1 followed by year, month and day; if I ever
want to change that, I can increment the initial 1.
FileDescription is taken from the existing DESCRIPTION string provided
to each puzzle() statement in CMakeLists.txt.
This means that puzzles.rc now always defines at least one resource,
so we can remove the workaround for MinGW's windres not being able to
cope with an empty .rc file, which added a dummy resource in the
absence of an icon.
There's no reason to put the .rc file into developer tools like
galaxieseditor at all. Its current job is to add an icon, and those
tools don't have any. I'm about to add version information, and they
won't have that either (in particular, no description string like the
games do).
The CLI developer tools already don't include puzzles.rc, and GUI dev
tools are more like those than they are like puzzles.
puzzles.rc was being added to an aux GUI tool's source file list by
get_platform_puzzle_extra_source_files(), which is called for aux GUI
tools as well as for puzzles proper. However, it's not as simple as
just eliminating that call, because on Unix, we _do_ need to add the
same extra source files to GUI dev tools that we do for puzzles,
because gtk.c contains external references to either an array of the
puzzle's icons or an empty array indicating that there aren't any, so
_something_ has to provide that.
So instead, get_platform_puzzle_extra_source_files now takes an extra
argument saying whether the program is a real puzzle or an aux tool;
windows.cmake leaves out puzzles.rc in the latter case, but unix.cmake
puts the icon array in unconditionally.
This compile-time definition switches the game into showing a distinct
non-negative integer for each vertex, instead of indistinguishable
blobs.
Its main use to me in the past has been when I'm trying to planarise
'real' graphs, that is, graphs I got from outside the game and wanted
a planar embedding of. Having made one in Untangle's UI I could then
read off which vertex was which.
That's an unusual use of the game, but _might_ be useful to someone
else. Perhaps a more interesting use of this feature would be to
direct someone else's play verbally - it would be much easier to tell
them which vertex to click on that way!
I just found this #define in the Untangle source code, which I'd
completely forgotten was there. It causes each graph edge to be
highlighted in red if another edge crosses it, so that when you only
have a small number of crossings left to sort out, it's obvious where
they are.
Now we have a preferences system, there's no need to make this a
compile-time option! We can make it run-time selectable, for users who
want the extra help.
Chris Boyle reports that a few users of the Android port were confused
by this, e.g. https://github.com/chrisboyle/sgtpuzzles/issues/624 .
(That seems surprising to me, since I view Map as extremely closely
related to Solo - both are special cases of the general game class
'here is a partial k-colouring of a graph, find the unique total
k-colouring that extends it', just with different ranges of k and
different valid graphs. And surely nobody approaches a Sudoku puzzle
and expects to be able to rub out provided clues they don't like! But
I suppose if you're thinking of Map as a completely separate puzzle
then perhaps that analogy doesn't have the same force.)
In Jigsaw Solo, block boundaries aren't convex, so it's possible for
one of them to have an inward corner. If that corner is in the top
left of a selectable cell, and you right-click that cell to display
the pencil-mode 'cursor' in the form of a triangle in the top left,
then the cursor was accidentally drawn on top of the block boundary,
where it ought to be underneath it.
For example, in game id 5j:d1d4_4c3_1d2d,bb_baaa_dca_baaba, right-
clicking in the bottom right square of the grid demonstrates the
problem.
Jonas Kölker fixed this for Keen in 2015, in commit 6482ed0e3c886af.
This is the identical fix, in Solo's very similar-looking drawing
routine. I feel embarrassed to have taken eight years to get round to
it!
The loop that selects one of the disconnected regions (represented as
equivalence classes in a dsf) to _not_ highlight as an error was
failing to call dsf_canonify() to get the canonical element of the
class.
Instead, it was relying on having met the canonical element of the
class first, because it iterates up the array in order, and in the old
dsf implementation, canonical elements were always minimal ones. But
the DSF refactoring made that untrue, so now we have to explicitly
canonify each value we come to.
Thanks to Steffen Bauer for the diagnosis and suggested fix.
A user reports that trying to generate a 2x2 or 3x3 puzzle at Tricky
difficulty causes the generator to hang, for the usual reason that
there aren't any - puzzles of that size are either ambiguous or Easy.
The usual response in this code base is to quietly downgrade the
puzzle difficulty when absolutely necessary, so here's some code to do
that (and also for 2x3, which the user didn't test, but unsurprisingly
behaves the same way).
'height', not 'neight'. Apparently has been misspelled since the
puzzle was first committed. I suppose they look similar enough that it
never caused a problem.
Thanks to Steffen Bauer for spotting this. The call to
midend_get_params(me) was making a duplicate of me->params, and
nothing was freeing it.
Since the game_params is passed to request_keys as a const pointer, it
should be safe to pass me->params itself, so that instead of adding a
free, we can remove the unnecessary allocation.
On a device with a phone keypad, driving Guess by typing numbers rather
than using the arrow keys seems natural. But if you're going to do
that, showing the labels makes it a lot easier. KaiOS doesn't have any
way for the user to control this, so we should default to the friendlier
state.
Not that I actually need it, but it's just as easy to load multiple
environment <script>s from the DOM as it is to load one, so we may as
well do that. Since only one element can have id="environment", we do
this by matching class="environment" as well.
It will be useful on KaiOS to be able to specify default user
preferences that aren't the standard ones, in the same way that we
specify some environment variables. As with environment variables, we
can now do this be embedding a <script> element in the HTML like this:
<script class="preferences" type="text/plain">
show-labels=true
</script>
These are loaded before the preferences from localStorage, so they just
set defaults and can be overridden by the user (but not on KaiOS yet,
because we still don't have dialogue boxes there).
The js_canvas_get_preferred_size() function was declining to suggest a
size for the puzzle if document.readyState wasn't "complete". I think
my idea here was that if the document wasn't fully loaded then I
couldn't trust the size of the containing <div>. While this was true,
declining to provide a size didn't help much since the puzzle still
needed a size, and the size of the containing <div> was the best guess
we had.
Now that function always returns the size of the containing <div> if
it exists. This appears to mean that puzzles don't show a brief flash
of being the wrong size on KaiOS. That was particularly visible with
Flood, where the wrong-size version had borders around the tiles that
the right-size version lacked. The containing <div> isn't used on the
standard Web versions, so there's no change to behaviour there.
In grid-snapping mode, Untangle was still recording vertex positions
in increments of one pixel. This meant that if you positioned
vertices on a small window, then enlarged the window and positioned
more vertices, the two sets of vertices generally wouldn't line up
with one another. This was annoying, and obviously silly when
Untangle has a resolution-independent co-ordinate system. So now the
snapped positions are recorded in a form that doesn't depend on the
tilesize.
If you clicked somewhere that had no effect (outside the grid or on a
square matching the colour of the top-left corner), interpret_move()
would return MOVE_NO_EFFECT (previously NULL) even though it had unset
ui->cursor. So the keyboard cursor would remain visible until the
next window resize (or similar) when it would vanish. Now
interpret_move() correctly returns MOVE_UI_UPDATE in these cases, so
the cursor vanishes immediately.
If you clicked somewhere that had no effect (on an immutable square or
a middle click on an empty square), interpret_move() would return NULL
even though it had unset ui->cursor. So the keyboard cursor would
remain visible until the next window resize (or similar) when it would
vanish. Now interpret_move() correctly returns MOVE_UI_UPDATE in
these cases, so the cursor vanishes immediately.
I missed this in my main commit for UI preferences
(4227ac1fd5dc25c247e7526526079b85e1890766) because it wasn't documented.
Now it is documented and it has a preference.
