When an island changes colour (because it becomes locked or
highlighted, or goes back to plain COL_FOREGROUND from one of those
states), we were just redrawing a filled circle over the previous one,
which only really worked before antialiasing was introduced.
Fixed by reworking the entire drawing edifice to be grid-square based,
so that every grid square is either redrawn in full or left alone.
Grid squares come in two types - island and bridge - but a bridge
square can have neighbouring islands overlap into it, and the bridges
entering an island overlap the island square too, so we end up with
quite a large collection of bitfields describing each square's
contents, and some care must be taken to draw each square in the right
order.
[originally from svn r10282]
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]
first loop only handle rightward or downward bridges (on the basis
that that way every bridge is looked at once rather than twice). This
seems to be breaking in the wake of recent changes to the solver, in
cases such as when island A is left of island B and has enough other
outgoing edges that only one bridge remains to potentially go to B,
but B is as yet unconstrained. In this situation the only code which
is able to adjust the maximum bridge count for that edge is the stage
3 solver (nothing else calls solve_join with is_max true), but it will
only do so if it _tries_ putting two bridges there and finds it
impossible, and when it starts from island A it won't even try.
Game ID which was insoluble just before this commit:
15x15m2:2a4d3b3c2h2d2a2a3c3w4a3m1d1a4a5a2d4d6e4q3e6a2a1e1b2g3a3o2g1d32l4b2c3a4c2b22l4a
This probably means I've done something else in recent checkins which
was not in accordance with the original solver design. However, this
fix will do for the moment.
[originally from svn r9548]
Simplest fix is to just remove the 'n' parameter from
solve_island_subgroup, replacing it with a robust island_countbridges.
[originally from svn r9547]
(I'm confident these can't happen. maxb is initialised whenever we
break from the first loop with y < h, and when we don't break from
that loop the second loop which uses maxb is run zero times. But gcc
can't work that out, sigh.)
[originally from svn r9546]
the possibility that an island might form an isolated subgraph by
connecting to one of its neighbours (and, if so, reducing the maximum
bridge count in that direction so that some bridge would have to go
elsewhere), but we were not also considering the possibility that it
might form an isolated subgraph by connecting to _more_ than one of
its neighbours. For instance, if you have a 3 adjacent to a 1, a 2 and
something else, then at least one bridge must go to the something-else.
Previously insoluble test case:
10x10m2:a2b4a5a2a2a1ga2d3b33a3a4c2aa3e1a22b2a4b4aa3b1a2b33a1e3aa2a1a2c23a3a3a4a2a
[originally from svn r9543]
a better upper bound on the number of bridges leaving a given island
in a given direction was not counted as having 'done something'; so a
solver run could make several such deductions, but then terminate in
the belief that it hadn't achieved anything, when just going back
round the main solver loop would have enabled it to make further
deductions based on those new bounds.
[originally from svn r9377]
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]
thereafter read. Most of these changes are just removal of pointless
stuff or trivial reorganisations; one change is actually substantive,
and fixes a bug in Keen's clue selection (the variable 'bad' was
unreferenced not because I shouldn't have set it, but because I
_should_ have referenced it!).
[originally from svn r9164]
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]
bridges that could go to an island, the game was not correctly
accounting for existing bridges in all circumstances.
(E.g. in 7x7m2:2a6a2a1g4a6c4i1a1h23c2b, connect the top right 1 to
the 2 left of it, and the 6 left of that correctly lights up red.
But now connect the 6 to the 6 below it, and it wrongly unlights
again.)
[originally from svn r8905]
_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]
is mostly done with ifdefs in windows.c; so mkfiles.pl generates a
new makefile (Makefile.wce) and Recipe enables it, but it's hardly
any different from Makefile.vc apart from a few definitions at the
top of the files.
Currently the PocketPC build is not enabled in the build script, but
with any luck I'll be able to do so reasonably soon.
[originally from svn r7337]
structures, meaning that ad-hoc initialisation now doesn't work.
Hence, this checkin converts all ad-hoc dsf initialisations into
calls to dsf_init() or snew_dsf(). At least, I _hope_ I've caught
all of them.
[originally from svn r6888]
warnings require two more variables to be explicitly initialised. In
fact these variables are reliably initialised by a subfunction; gcc3
was happy to assume I knew what I was doing when it couldn't prove
they were definitely used uninitialised, whereas gcc4 apparently
takes the view that the onus is on me to allow it to prove they
_aren't_. I regard this as a step backwards, since the effect will
be to make explicit initialisation commonplace in cases where the
initialiser value is chosen arbitrarily and never expected to be
used, at which point (a) it will be less clear which initialisers
have genuine purpose and which are compiler-placating fluff, and (b)
valgrind's run-time uninitialised-data tracking will become less
useful. Still, the effect doesn't seem great as yet, so here's the
gcc4-placating checkin.
[originally from svn r6508]
- the highlighting for a set of 4 lines spilled outside the tile, so would
leave white residue if undone;
- the endpoints of sets of 4 lines were not completely overprinted by the
circle of an island (at least on Windows), which was untidy.
Fixed by reducing the gap width for groups of lines which wouldn't otherwise
fit in a tile (only).
[originally from svn r6421]
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]
