I don't know how I've never thought of this before! Pretty much every
game in this collection has to have a mechanism for noticing when
game_redraw is called for the first time on a new drawstate, and if
so, start by covering the whole window with a filled rectangle of the
background colour. This is a pain for implementers, and also awkward
because the drawstate often has to _work out_ its own pixel size (or
else remember it from when its size method was called).
The backends all do that so that the frontends don't have to guarantee
anything about the initial window contents. But that's a silly
tradeoff to begin with (there are way more backends than frontends, so
this _adds_ work rather than saving it), and also, in this code base
there's a standard way to handle things you don't want to have to do
in every backend _or_ every frontend: do them just once in the midend!
So now that rectangle-drawing operation happens in midend_redraw, and
I've been able to remove it from almost every puzzle. (A couple of
puzzles have other approaches: Slant didn't have a rectangle-draw
because it handles even the game borders using its per-tile redraw
function, and Untangle clears the whole window on every redraw
_anyway_ because it would just be too confusing not to.)
In some cases I've also been able to remove the 'started' flag from
the drawstate. But in many cases that has to stay because it also
triggers drawing of static display furniture other than the
background.
The Rockbox frontend allows games to be displayed in a "zoomed-in"
state targets with small displays. Currently we use a modal interface
-- a "viewing" mode in which the cursor keys are used to pan around
the rendered bitmap; and an "interaction" mode that actually sends
keys to the game.
This commit adds a midend_get_cursor_location() function to allow the
frontend to retrieve the backend's cursor location or other "region of
interest" -- such as the player location in Cube or Inertia.
With this information, the Rockbox frontend can now intelligently
follow the cursor around in the zoomed-in state, eliminating the need
for a modal interface.
This change doesn't alter the overall power of the Dominosa solver; it
just moves the boundary between Hard and Extreme so that fewer puzzles
count as Hard, and more as Extreme. Specifically, either of the two
cases of set analysis potentially involving a double domino with both
squares in the set is now classed as Extreme.
The effects on difficulty are that Hard is now easier, and Extreme is
at least easier _on average_. But the main purpose is the effect on
generation time: before this change, Dominosa Extreme was the slowest
puzzle present to generate in the whole collection, by a factor of
more than three. I think the forcing-chain deductions just didn't make
very many additional grids soluble, so that the generator had to try a
lot of candidates before finding one that could be solved using
forcing chains but not with all the other techniques put together.
This is a technique I've had on the todo list (and been using by hand)
for years: a domino can't be placed if it would divide the remaining
area of the grid into pieces containing an odd number of squares.
The findloop subsystem is already well set up for finding domino
placements that would divide the grid, and the new is_bridge query
function can now tell me the sizes of the area on each side of the
bridge, which makes it trivial to implement this deduction by simply
running findloop and iterating over the output array.
We've already spotted when a domino occurs twice in the _same_ forcing
chain. But now we also spot when it occurs twice in the same _pair_ of
complementary forcing chains, one in each of the two options. Then it
must appear in one of those two places, and hence, can't appear
anywhere else.
This is necessary to solve the following test puzzle that someone sent
me in 2006 and I just recovered from my email archive:
6:65111036543150325534405211110064266620632365204324442053
Without this new deduction, the previous solver can't solve that
puzzle even at full power, but the half-solved state it leaves the
grid in has an obvious move in the top right corner (placing the 6-2
domino vertically in that corner forces two 3-0s to its left). Now
that kind of move can be made too, and the solver can handle this
puzzle (grading it as Hard).
I realised that even with the extra case for a double domino
potentially using two squares in a set, I'd missed two tricks.
Firstly, if the double domino is _required_ to use two of the squares,
you can rule out any placement in which it only uses one. But I was
only ruling out those in which it used _none_.
Secondly, if you have the same number of squares as dominoes, so that
the double domino _can_ but _need not_ use two of the squares, then I
previously thought there was no deduction you could make at all. But
there is! In that situation, the double does have to use _one_ of the
squares, or else there would be only the n-1 heterogeneous dominoes to
go round the n squares. So you can still rule out placements for the
double which fail to overlap any square in the set, even if you can't
(yet) do anything about the other dominoes involved.
Now we don't just ensure that alloc_try_hard arranged a confounder for
every domino; we also make sure that the full Basic-mode solver can't
place even a single domino with certainty.
Now, as well as grading a puzzle by the highest difficulty it needed
during its solution, I can check _how much_ of a given puzzle is
soluble if you remove the higher difficulty levels.
The new Hard and Extreme difficulty levels allow you to make a start
on a grid even if there is no individual domino that can be easily
placed. So it's more elegant to _enforce_ that, in the same way that
Hard-mode Slant tries to avoid the initial toeholds that Easy mode
depends on.
Hence, I've refactored the domino layout code into several alternative
versions. The new one, enabled at Hard mode and above, arranges that
every domino has more than one possible position, so that you have to
use some kind of hard deduction to even get off the ground.
While I'm at it, the old layout system has had a makeover: in the
course of its refactoring, I've arranged to iterate over the domino
values _and_ locations in random order, instead of going over the
locations in grid order. The idea is that that might eliminate a
directional bias. But more importantly, it changes the previous
meaning of random number seeds.
I decided not to go all the way up to order-9 Extreme, because that
takes a lot of CPU to generate. People can select it by hand if they
don't mind that.
As with several other puzzles, the harder difficulty levels turn out
to be impossible to generate at very small sizes, which I fudge by
replacing them with the hardest level actually feasible.
This technique borrows its name from the Solo / Map deduction in which
you find a path of vertices in your graph each of which has two
possible values, such that a choice for one end vertex of the chain
forces everything along it. In Dominosa, an approximate analogue is a
path of squares each of which has only two possible domino placements
remaining, and it has the extra-useful property that it's
bidirectional - once you've identified such a path, either all the odd
domino placements along it must be right, or all the even ones. So if
you can find an inconsistency in either set, you can rule out the
whole lot and settle on the other set.
Having done that basic analysis (which turns out to be surprisingly
easy with an edsf to help), there are multiple ways you can actually
rule out one of the same-parity chains. One is if the same domino
would have to appear twice in it; another is if the set of dominoes
that the chain would place would rule out all the choices for some
completely different square. There are probably others too, but those
are the ones I've implemented.
In particular, reorganise the priorities. I think forcing chains are
the most important thing that still wants adding; the parity search
would be easy enough but I don't know how often it would actually be
_useful_; the extended set analysis would be nice but I don't know how
to make it computationally feasible.
I've always had the vague idea that the usual set analysis deduction
goes wrong when there are two adjacent squares, because they might be
opposite ends of the same domino and mess up the count. But I just
realised that actually you can correct for that by adjusting the
required count by one: if you have four 0 squares which between them
can only be parts of 0-0, 0-1 and 0-2, then the only way this can work
is if two of them are able to be the 0-0 - but in that case, you can
still eliminate those dominoes from all placements elsewhere. So set
analysis _can_ work in that situation; you just have to compensate for
the possible double.
(This enhanced form _might_ turn out to be something that needs
promoting into a separate difficulty level, but for the moment, I'll
try leaving it in Hard and seeing if that's OK.)
This is another thing I've been doing with my own brain for ages as a
more interesting alternative to scouring the grid for the simpler
deduction that must be there somewhere - but now the solver can
understand it too, so it can generate puzzles that _need_ it (or at
least need something beyond the simpler strategies it understands).
Currently, there are just two difficulty levels. 'Basic' is the same
as the old solver; 'Trivial' is the subset that guarantees the puzzle
can be solved using only the two simplest deductions of all: 'this
domino can only go in one place' and 'only one domino orientation can
fit in this square'.
The solver has also acquired a -g option, to grade the difficulty of
an input puzzle using this system.
The new solver should be equivalent to the previous solver's
intelligence level, but it's more usefully split up into basic
data-structure maintenance and separate deduction routines that you
can omit some of. So it's a better basis to build on when adding
further deductions or dividing the existing ones into tiers.
The new solver also produces much more legible diagnostics, when the
command-line solver is run in -v mode.
I've made the existing optional solver diagnostics appear as the
verbose output of the solver program. They're not particularly legible
at the moment, but they're better than nothing.
This is the main bulk of this boolification work, but although it's
making the largest actual change, it should also be the least
disruptive to anyone interacting with this code base downstream of me,
because it doesn't modify any interface between modules: all the
inter-module APIs were updated one by one in the previous commits.
This just cleans up the code within each individual source file to use
bool in place of int where I think that makes things clearer.
This commit removes the old #defines of TRUE and FALSE from puzzles.h,
and does a mechanical search-and-replace throughout the code to
replace them with the C99 standard lowercase spellings.
encode_params, validate_params and new_desc now take a bool parameter;
fetch_preset, can_format_as_text_now and timing_state all return bool;
and the data fields is_timed, wants_statusbar and can_* are all bool.
All of those were previously typed as int, but semantically boolean.
This commit changes the API declarations in puzzles.h, updates all the
games to match (including the unfinisheds), and updates the developer
docs as well.
I've been playing this game a fair bit recently, and it's probably
time I jotted down some of the deductions I've been doing in my own
brain that the game doesn't know about. (Also I had an algorithmic
thought about the area-parity technique.)
This function gives the front end a way to find out what keys the back
end requires; and as such it is mostly useful for ports without a
keyboard. It is based on changes originally found in Chris Boyle's
Android port, though some modifications were needed to make it more
flexible.
This allows me to use different types for the mutable, dynamically
allocated string value in a C_STRING control and the fixed constant
list of option names in a C_CHOICES.
Now midend.c directly tests the returned pointer for equality to this
value, instead of checking whether it's the empty string.
A minor effect of this is that games may now return a dynamically
allocated empty string from interpret_move() and treat it as just
another legal move description. But I don't expect anyone to be
perverse enough to actually do that! The main purpose is that it
avoids returning a string literal from a function whose return type is
a pointer to _non-const_ char, i.e. we are now one step closer to
being able to make this code base clean under -Wwrite-strings.
To do this, I've completely replaced the API between mid-end and front
end, so any downstream front end maintainers will have to do some
rewriting of their own (sorry). I've done the necessary work in all
five of the front ends I keep in-tree here - Windows, GTK, OS X,
Javascript/Emscripten, and Java/NestedVM - and I've done it in various
different styles (as each front end found most convenient), so that
should provide a variety of sample code to show downstreams how, if
they should need it.
I've left in the old puzzle back-end API function to return a flat
list of presets, so for the moment, all the puzzle backends are
unchanged apart from an extra null pointer appearing in their
top-level game structure. In a future commit I'll actually use the new
feature in a puzzle; perhaps in the further future it might make sense
to migrate all the puzzles to the new API and stop providing back ends
with two alternative ways of doing things, but this seemed like enough
upheaval for one day.
puzzle backend function which ought to have it, and propagate those
consts through to per-puzzle subroutines as needed.
I've recently had to do that to a few specific parameters which were
being misused by particular puzzles (r9657, r9830), which suggests
that it's probably a good idea to do the whole lot pre-emptively
before the next such problem shows up.
[originally from svn r9832]
[r9657 == 3b250baa02a7332510685948bf17576c397b8ceb]
[r9830 == 0b93de904a98f119b1a95d3a53029f1ed4bfb9b3]
new_desc. Oddities in the 'make test' output brought to my attention
that a few puzzles have been modifying their input game_params for
various reasons; they shouldn't do that, because that's the
game_params held permanently by the midend and it will affect
subsequent game generations if they modify it. So now those arguments
are const, and all the games which previously modified their
game_params now take a copy and modify that instead.
[originally from svn r9830]
basically just so that it can divide mouse coordinates by the tile
size, but is definitely not expected to _write_ to it, and it hadn't
previously occurred to me that anyone might try. Therefore,
interpret_move() now gets a pointer to a _const_ game_drawstate
instead of a writable one.
All existing puzzles cope fine with this API change (as long as the
new const qualifier is also added to a couple of subfunctions to which
interpret_move delegates work), except for the just-committed Undead,
which somehow had ds->ascii and ui->ascii the wrong way round but is
otherwise unproblematic.
[originally from svn r9657]
midend_status(), and given it three return codes for win, (permanent)
loss and game-still-in-play. Depending on what the front end wants to
use it for, it may find any or all of these three states worth
distinguishing from each other.
(I suppose a further enhancement might be to add _non_-permanent loss
as a fourth distinct status, to describe situations in which you can't
play further without pressing Undo but doing so is not completely
pointless. That might reasonably include dead-end situations in Same
Game and Pegs, and blown-self-up situations in Mines and Inertia.
However, I haven't done this at present.)
[originally from svn r9179]
state is in a solved position, and a midend function wrapping it.
(Or, at least, a situation in which further play is pointless. The
point is, given that game state, would it be a good idea for a front
end that does that sort of thing to proactively provide the option to
start a fresh game?)
[originally from svn r9140]
_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]
function, since it took no parameters by which to vary its decision,
and in any case it's hard to imagine a game which only
_conditionally_ wants a status bar. Changed it into a boolean data
field in the backend structure.
[originally from svn r6417]
was actually using it, and also it wasn't being called again for
different game states or different game parameters, so it would have
been a mistake to depend on anything in that game state. Games are
now expected to commit in advance to a single fixed list of all the
colours they will ever need, which was the case in practice already
and simplifies any later port to a colour-poor platform. Also this
change has removed a lot of unnecessary faff from midend_colours().
[originally from svn r6416]
game_print(), wherever feasible. This fixes a specific bug in Loopy
(James H's new field ds->linewidth wasn't being set up, leading to
corrupted print output), but I've made the change in all affected
files because it also seems like a generally good idea to encourage
it for future games, to prevent other problems of this type.
There is one slight snag, which is that Map _can't_ do this because
its game_set_size() also initialises a blitter. I could fix this by
abstracting the common parts of Map's game_set_size() out into a
subfunction called by game_set_size() and also called directly by
game_print(); alternatively, I could introduce a means of
determining whether a `drawing *' was for screen or printing use.
Not sure which yet.
[originally from svn r6340]
as seen by the back ends from the one implemented by the front end,
and shoved a piece of middleware (drawing.c) in between to permit
interchange of multiple kinds of the latter. I've also added a
number of functions to the drawing API to permit printing as well as
on-screen drawing, and retired print.py in favour of integrated
printing done by means of that API.
The immediate visible change is that print.py is dead, and each
puzzle now does its own printing: where you would previously have
typed `print.py solo 2x3', you now type `solo --print 2x3' and it
should work in much the same way.
Advantages of the new mechanism available right now:
- Map is now printable, because the new print function can make use
of the output from the existing game ID decoder rather than me
having to replicate all those fiddly algorithms in Python.
- the new print functions can cope with non-initial game states,
which means each puzzle supporting --print also supports
--with-solutions.
- there's also a --scale option permitting users to adjust the size
of the printed puzzles.
Advantages which will be available at some point:
- the new API should permit me to implement native printing
mechanisms on Windows and OS X.
[originally from svn r6190]
do during construction which massively increases (by over a factor
of four with default parameters) the probability that any given
randomly generated grid will be uniquely solvable.
[originally from svn r6096]
