This adds a "half-grid" cursor mode, settable via a preference, which
doubles the resolution of the keyboard cursor, so that it can be over a
square center, vertex, or edge. The cursor select buttons then toggle the
edge directly under the cursor.
There are two advantages to this new behavior. First, the game can now be
played with only the cursor keys, doing away with the need to hold Control
or Shift, which are not currently emulated on Rockbox. And second, the new
interface is arguably more discoverable than the legacy mode,
which is still retained as a user preference.
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.)
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.)
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.
I missed this in my previous addition of preferences for UI controls
(4227ac1fd5dc25c247e7526526079b85e1890766) because it wasn't documented.
Now it is documented and it has a preference.
I've phrased it as showing possible bridge locations, which doesn't
really make clear that "possible" relates only to the locations of
islands and not to anything already placed. Improvements welcome!
Some puzzles have keys that make changes to the display style in ways
that would probably have been user preferences if they had existed.
I've added a user preference for each of these. The keys still work,
and unlike the preferences can be changed without saving any state.
The affected settings are:
* Labelling colours with numbers in Guess ("L" key)
* Labelling regions with numbers in Map ("L" key)
* Whether monsters are shown as letters or pictures in Undead ("A" key)
Here, user preferences are stored in localStorage, so that they can
persist when you come back to the same puzzle page later.
localStorage is global across a whole web server, which means we need
to take care to put our uses of it in a namespace reasonably unlikely
to collide with unrelated web pages on the same server. Ben suggested
that a good way to do this would be to store things in localStorage
under keys derived from location.pathname. In this case I've appended
a fragment id "#preferences" to that, so that space alongside it
remains for storing other things we might want in future (such as
serialised saved-game files used as quick-save slots).
When loading preferences, I've chosen to pass the whole serialised
preferences buffer from Javascript to C as a single C string argument
to a callback, rather than reusing the existing system for C to read
the save file a chunk at a time. Partly that's because preferences
data is bounded in size whereas saved games can keep growing; also
it's because the way I'm storing preferences data means it will be a
UTF-8 string, and I didn't fancy trying to figure out byte offsets in
the data on the JS side.
I think at this point I should stop keeping a list in the docs of
which frontends support preferences. Most of the in-tree ones do now,
and that means the remaining interesting frontends are ones I don't
have a full list of. At this moment I guess no out-of-tree frontends
support preferences (unless someone is _very_ quick off the mark), but
as and when that changes, I won't necessarily know, and don't want to
have to keep updating the docs when I find out.
The low-level load and save routines are basically copy-pasted from
gtk.c, with only minor changes to deal with the different locally
appropriate config file location and the lack of savefile_write_ctx.
If you want to remove your saved preferences for a puzzle for any
reason (perhaps because of one of those unsympathetic managers, or
perhaps because it's become corrupted in some way), you can of course
manually go and find the config file and delete it. But if you're not
sure where it is, it's helpful to have a method of telling the puzzle
itself to delete the config file.
Perhaps it would be useful to expose this in the GUI as well, though
I'm not quite sure where is the best place to put it.
(_Perhaps_ it would also be useful to have a more thorough option that
deleted _all_ puzzles' configurations - although that would involve
telling every separate puzzle binary in this collection what all the
other ones' names are, which would be an entirely new build headache.)
Finally, some user-visible behaviour changes as a payoff for all that
preparation work! In this commit, the GTK puzzles get a 'Preferences'
option in the menu, which presents a dialog box to configure the
preference settings.
On closing that dialog box, the puzzle preferences are enacted
immediately, and also saved to a configuration file where the next run
of the same puzzle will reload them.
The default file location is ~/.config/sgt-puzzles/<puzzlename>.conf,
although you can override the .config dir via $XDG_CONFIG_HOME or
override the Puzzles-specific subdir with $SGT_PUZZLES_DIR.
This is the first commit that actually exposes all the new preferences
work to the user, and therefore, I've also added documentation of all
the current preference options.
I found a plausible looking Web page claiming that various different
sizes of cross are soluble, and some of them are quite widespread. I've
enabled the ones that are symmetric enough that the existing game
generator can lay them out.
For most puzzles, the manual tries to at least mention its origin.
Wikipedia suggests that the precise inventor of the 15-puzzle is a bit
uncertain, but US patent number 207124 definitely describes it in
1878, so "dates from the 1870s" seems pretty solid.
Now rather than mucking around with the cursor keys, you can just type a
four-digit number and press Enter. Of course, if you still want to muck
around with the cursor keys they work the same as before.
Since Backspace was already assigned to clear the peg under the cursor,
I haven't co-opted it for the obvious action of clearing the peg to the
left of the cursor and moving the cursor left. The left arrow key is a
reasonable alternative anyway.
For consistency, 'L' now labels the pegs with numbers rather than
letters, and is documented.
Most of the old URLs don't work any more. As far as I can see, the
new pages have no Flash, and even if they did very few browsers will
still support it.
This is similar in concept to Minesweeper, in that each clue tells you
the number of things (in this case, just 'black squares') in the
surrounding 3x3 grid section.
But unlike Minesweeper, there's no separation between squares that can
contain clues, and squares that can contain the things you're looking
for - a clue square may or may not itself be coloured black, and if
so, its clue counts itself.
So there's also no hidden information: the clues can all be shown up
front, and the difficulty arises from the game generator choosing
which squares to provide clues for at all.
Contributed by a new author, Didi Kohen. Currently only has one
difficulty level, but harder ones would be possible to add later.
Printing is only available in GTK versions >= 2.10. We can only embed
the page setup dialog on GTK >= 2.18, so on a GTK version less than
that, we must use a separate page setup dialog.
In GTK, printing is usually done one page at a time, so also modify
printing.c to allow printing of a single page at a time.
Create a separate drawing API for drawing to the screen and for
printing. Create a vtable for functions which need to be different
depending on whether they were called from the printing or drawing
API.
When a function is called from the printing API, it is passed a
separate instance of the frontend than if it were called from the
drawing API. In that instance of the frontend, an appropriate vtable
is available depending on whether it was called from the printing or
drawing API.
The low-level functions used for printing are enabled even if printing
is not enabled. This is in case we ever need to use them for something
other than printing with GTK. For example, using Cairo as a printing
backend when printing from the command line. Enabling the low-level
functions even when GTK printing is not available also allows them to
be compiled under as many build settings as possible, and thus lowers
the chance of undetected breakage.
Move the definition of ROOT2 from ps.c to puzzles.h so other files can
use it (gtk.c needs it for hatching).
Also add myself to the copyright list.
[Committer's note: by 'printing', this log message refers to the GTK
GUI printing system, which handles selecting a printer, printing to a
file, previewing and so on. The existing facility to generate
printable puzzles in Postscript form by running the GTK binaries in
command-line mode with the --print option is unaffected. -SGT]
Asher Gordon points out that when Michael Quevillon was added to the
LICENCE file in commit 8af0c2961, he didn't also make it in to the
copy of the same list in puzzles.but.
A user mailed me today having found it less than clear from the docs
that Galaxies will only accept a solution if the set of filled-in grid
edges consists of _exactly_ the ones that separate two distinct
regions, rather than consisting of _at least_ those and perhaps others
which neither break rotational symmetry or disconnect any region.
Chris Boyle points out that two of the rules are implicitly intended
to be read as only applying if a previous rule hadn't already decided
what would happen, and suggested that since not all readers infer that
priority order, it would be better to explicitly make them mutually
exclusive so that there can be no confusion about which one applies.
Where possible (mostly with the Nikoli links), they've been updated to their
modern locations. At least one link had to become a Wayback Machine link;
I didn't bother making the floodit.appspot.com link a Wayback one because
there's no content there without the backing of Google App Engine. There
are other implementations online nowadays, of course, but I didn't want to
change the meaning of the text if at all possible. In addition, I added
Flash warnings for the Nikoli pages that now use Flash for instructions.
The web page currently assumes it's called 'rect' rather than
'rectangles', because the web-page building script uses the first
field of each line of gamedesc.txt, same as the Unix binary name.
Rather than add another confusingly-almost-identical field to that
file, it's easier to just rename this one docs section to make the
assumption of equality hold.
- Lay bridges (crosess) with Control-arrow (Shift-arrow)
- Jump (non-orthogonally) to nearby islands with number keys, a..f
- Mark islands as done with a single tap on the space bar
Pressing Ctrl-arrow or Shift-arrow on a tile now moves the row or
column under the tile. With Ctrl, the cursor moves as well so you can
keep making moves that affect the same tile; with Shift, the cursor
stays put so you can keep making moves that affect the same location.
Pressing H now suggests the lexicographically first row consistent
with all previous feedback.
The previous function of the H key to toggle a hold marker on the
current peg is now performed by Space / CURSOR_SELECT2, which is more
in line with other puzzles anyway.
This is really an incremental solver. It alternates between solving
rows and solving columns. Each row and column is solved one piece at
a time. Except for some temporary trickery with the last two pieces
in a row or column, once a piece is solved it is never moved again.
(On non-square grids it first solves some rows or some columns until
the unsolved part is a square, then starts alternating.)
