checks. He thinks they were harmless (due to being followed by other
range checks in RIGHTOF_DOT and friends) but it clearly can't hurt
to fix them anyway.
[originally from svn r6709]
generalisation of the previous deduction involving two 3s or two 1s
either adjacent or separated by a row of contiguous 2s. I always
said that was an ugly loop and really ought to arise naturally as a
special case of something more believable, and here it is.
The practical upshot is that Hard mode has just become slightly
harder: some grids generated by the new Slant will be unsolvable by
the old one's solver. I don't think it's become _excessively_ more
hard; I think I'm happy with the new difficulty level. (In
particular, I don't think the new level is sufficiently harder than
the old to make it worth preserving the old one as Medium or
anything like that.)
[originally from svn r6591]
Fix it, add holds to the undo history (by analogy with Net), and save the
current holds in saved games.
Also fix a couple of unrelated minor issues with string encoding.
[originally from svn r6590]
washed-out yellow and green in Guess into their full-brightness pure
forms. This makes them hard to see against some backgrounds, so I'm
also surrounding all coloured pegs with black outlines. Looks a
little cartoony, but I think it's an overall improvement on the
previous look.
[originally from svn r6589]
believe a square to be empty, you find out instantly and lethally,
but if you erroneously believe a square to be full you can
occasionally (when it doesn't cause a complementary square to be
assumed empty) not notice until you find at the very end of the game
that you're one mine heavy. To help with this, here's an error
highlighting patch: any number square surrounded by an excess of
flags will now light up red. This should be an unintrusive change,
because it will never happen unless you make a mistake.
[originally from svn r6580]
laser-indistinguishable from the right solution _but_ has a number
of balls outside the acceptable range does not report an error. His
example was the game ID w8h8m5M5:1e3e6e80fa3e16265ccef7ca , omitting
the rightmost ball in the second row.
[originally from svn r6542]
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]
midend_rewrite_statusbar() and check the result against the last
string returned. This is now done centrally in drawing.c, and the
front end status bar function need only do what it says on the tin.
While I'm modifying the prototype of drawing_init(), I've also
renamed it drawing_new() for the same reason as random_new() (it
_allocates_ a drawing object, rather than just initialising one
passed in).
[originally from svn r6420]
which didn't actually need it. It was originally introduced in
Fifteen to suppress animation on Solve moves, but midend.c now does
that centrally unless the game specifically instructs it otherwise.
Therefore, just_used_solve is obsolete in all games which previously
used it. (Mines was even worse: it scrupulously maintained the
correctness of the field but never used it!)
Untangle is exempt from this cleanup: its `just_solved' field is
used to change the _length_ of the animation on Solve moves, not to
suppress it entirely, and so it has to stay.
[originally from svn r6419]
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]
shift right. It doesn't actually matter in the current code since
the input word only ever uses the bottom 9 bits, but if I ever
extended Mines to work in a triangular grid then all 16 bits might
be required. Fix this now, while I'm cleaning things up, so that it
won't bite me unexpectedly in future.
[originally from svn r6415]
assertion failures in portrait-type grids; retire an unused array in
the game generation function (my original generation strategy needed
it, but the final one didn't); correct a typo; further restrict the
generable sizes of game and include a special case for 4x4dt to
prevent a tight loop.
[originally from svn r6405]
maxflow.c. Also in this checkin, fixes to the OS X and GTK back ends
to get ALIGN_VNORMAL right. This is the first time I've used it! :-)
[originally from svn r6390]
using unwrappered malloc/free, leaving plenty of openings for out-
of-memory segfaults. Switch to using Puzzles's memory management,
which I should have done right at the start but can only assume I
forgot about.
[originally from svn r6388]
differs between oldstate and state in only the hint bit should not
have a flip animation even if hints_active is TRUE. Flip animations
should only happen for tiles which are changing their primary state.
(Put like that, it seems so obvious.)
Test case which demonstrates this fix to be right and r6384 to be
wrong: 3x3:101000000000000000000,300 . Hit Solve immediately and
then click on the red-highlighted squares.
[originally from svn r6385]
[r6384 == dd175e490a197026210ba4432eec6236971c6173]
always got a flip animation even when it wasn't one of the ones
being turned, and a square with no effect at all was still counting
as a move.
Since it's an invariant of Flip's internal generator that every
square includes itself as an effect, this never comes up in auto-
generated games.
[originally from svn r6384]
in the game description, the solver will fail to notice it and
overrun an array leading to assertion failure, silent wrong answers
or (in extreme cases) segfaults. Hence, validate_desc() now spots
them and kicks them out.
[originally from svn r6383]
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]
eliminates gratuitous duplication of the solver state every time it
goes round the main loop, in favour of the usual type of
`done_something' flag.
[originally from svn r6322]
- remove the backtracking `Hard' level, on the grounds that it was
incredibly slow and not really usable.
- introduce an `Easy' difficulty level below the standard one; many
people seem to find this puzzle unusually hard, so an easy level
is particularly helpful.
- highlight unfulfillable clue squares (but not yet any other types
of obvious error).
[originally from svn r6299]
r6160, I completely failed to ensure that generated grids were _at
most_ the required difficulty. It appears to have been only random
chance that prevented a request for a Trivial puzzle from producing
Extreme. Here's a one-line fix.
[originally from svn r6298]
[r6160 == e55838bc9b0d173ca539d0cfe714495b5c12b9dd]
ago, and nearly changed it to the obvious thing. After some thought,
though, I've decided the `bug' is better off unfixed, and added a
comment explaining why.
[originally from svn r6293]
