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]
victory roll so that adjacent arrows rotate in opposite directions,
giving the impression that they're an interlocking field of gears.
Possibly even more brain-twisting than the original version :-)
[originally from svn r9384]
beginning, we should wrap back to COL_B0+1 rather than COL_B0 itself,
so as not to reuse white. White should be special, and always indicate
a properly numbered square.
[originally from svn r9305]
than 26 separate linked chains of unnumbered squares: we now wrap from
'z' to an Excel-like 'aa', 'ab', ..., instead of falling off z into
punctuation and control characters.
[originally from svn r9304]
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]
additions of missing 'static' and explicit 'void' in parameter lists,
plus one or two other things like explicitly casting chars in variadic
argument lists to int and using DBL_MAX if HUGE_VAL isn't available.
[originally from svn r9166]
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]
- sometimes two regions would get the same letter
- immutable numbers could sometimes be modified
- immutable numbers are now not flagged as errors when they clash
(same as Solo's policy)
[originally from svn r8882]
reported as potentially-unused. (In fact, as far as I can tell, it's
only ever uninitialised in assertion-failing code paths, so not a
real bug.)
[originally from svn r8873]
assertion I crudely commented out has now been replaced with code
that clearly shows what you did wrong in the failing situation.
[originally from svn r8872]
long chain to a square numbered so low that the start of the chain
would have to go into negative numbers should not crash the game,
particularly when it happens as a momentary in-passing illustration.
I've fixed it for the moment just by removing the assertion. There's
probably a better fix which causes something less strange to happen
to the display as a result.
[originally from svn r8867]
