| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
Now we work out for ourselves how the drawing-area size relates to the
overall window size, by adding on the height of fe->menubar and/or
fe->statusbar.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
The check_valid() function was not verifying that each Killer cage
summed to the right thing! Thanks to Chris Goodyer for spotting it. I
wonder how nobody else has, in 8 years.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In commits 24848706e and adc54741f, I revamped the highlighting of
erroneous connected components of those two puzzles' solution graphs
in cases where a non-solution loop existed, so that the largest
component was considered correct and the smaller ones lit up in red.
I intended this to work in the cases where you have most of a correct
solution as one component and a small spurious loop as another (in
which case the latter lights up red), or conversely where your mostly
correct component was joined into a loop leaving a few edges out (in
which case the left-out edges again light up red). However, a user
points out that I overlooked the case where your mostly correct
solution is not all one component! If you've got lots of separate
pieces of path, and one tiny loop that's definitely wrong, it's silly
to light up all but the longest piece of path as if they're erroneous.
Fixed by treating all the non-loop components as one unit for these
purposes. So if there is at least one loop and it isn't the only thing
on the board, then we _either_ light up all loops (if they're all
smaller than the set of non-loop paths put together), _or_ light up
everything but the largest loop (if that loop is the biggest thing on
the board).
|
| |
|
|
|
|
|
|
|
|
|
| |
It isn't necessary to cause the right files to _exist_, because
makedist.sh is run from Buildscr which has already run mkauto. But it
turns out it _is_ important to get the relative timestamps of
Makefile.in and Makefile.am the right way round, otherwise somebody
who unpacks the tarball and runs 'configure' and 'make' will find make
tries to rebuild Makefile.in because it thinks Makefile.am is newer -
and if they don't have the right automake installed, or any automake,
that will fail.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is that annoying feature of up-to-date 'convert' in which
converting to or from a PNG file defaults to returning RGB values that
have been 'helpfully' gamma-corrected (or some such) from the exact
data stored in the source file to some nonsense you didn't want.
Usually the worst this causes is slightly washed-out looking graphics,
but in this case, since my entire aim was to squash the image into a
specific set of exact RGB values so as to turn it into a paletted
Windows icon file, it caused an actual build failure when the next
loop in icon.pl couldn't find the gamma-corrected values in its
expected palette map, and no wonder.
|
| |
|
|
|
|
| |
It actually went off this morning, after an upgrade of ImageMagick,
and I found that it contained both unprintable characters in the
colour description and the wrong variable in the coordinate display.
|
| |
|
|
|
|
|
| |
Between 5.5.6 and 5.5.9 the default output file name changed. To
defend against that potentially happening again, I'm now explicitly
specifying the output file name in the .iss source file (or rather, in
winiss.pl, which constructs it).
|
| |
|
|
|
| |
Thanks to Kevin Buzzard for spotting that relic of an outmoded version
control system.
|
| |
|
|
| |
Ahem. Left this out of yesterday's commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I've reused most of the install script I wrote for PuTTY recently,
minus the selectable-features dialog, and plus some preliminary Mason
templating to automatically build the right set of puzzle binaries
into the installer.
Stable GUIDs are autogenerated by the same technique I use in PuTTY's
Visual Studio project file generation: hash a fixed pile of randomly
generated bits (that is, randomly generated _once_ and used forever)
with each filename or other identifier and use those as your random
number source.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A user pointed out that Tracks could sometimes flash for completion
when there wasn't even a full path from A to B! And it looks as if
that wasn't even a mistake I introduced with the loop-checking revamp
this week.
Now I _think_ it's complete: we set ret=FALSE in check_completion
wherever we also produce an error highlight, and also whenever there
is no path connecting A with B. And if there is a path connecting A
with B, then any square not on the path becomes an error highlight.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pearl has more or less the same attitude to loops as Loopy does, in
that a loop is required in the solution but some loops during play
want to be highlighted as errors. So it makes sense to use the same
strategy for loop highlighting.
I've cloned-and-hacked the code from Loopy rather than abstracting it
out, because there were some fiddly differences in application (like
checking of untouched clues in Pearl). Perhaps some day I can come
back and make it all neater.
Also, while I'm here, I've cleaned up the loop_length field in
game_state, which was carefully set up by check_completion() but never
actually used for anything. (If I remember rightly, it was going to be
used for a fancy victory flash which never saw the light of day.)
|
| |
|
|
|
|
|
|
|
| |
I think this assertion must have been put under '#if 0' during early
development, and accidentally never taken out once the game started
actually working. Putting it back in doesn't cause the self-tests to
fail, so I'm reinstating it - if it does fail, I'd like to know about
it!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some people don't bother to use the right-click UI action that marks a
line as 'definitely not' rather than the initial default yellow
'unknown'. Previously, Loopy gave those people a UI annoyance for some
classes of mistake they made during solving: it would reliably
highlight a clue square with too _many_ edges around it, but not one
with too few - because in normal right-click-ful play, a clue with too
few LINE_YES only becomes an error when there aren't enough
LINE_UNKNOWN around it to potentially become the remaining YESes in
future.
This change arranges that once the player closes the loop, _then_ we
light up underfilled clues, on the basis that adding any further edge
would be an obvious error, so it's no longer sensible to assume that
the user might be planning to come back and do so.
(It's not a very timely notification of errors - it's easy to imagine
someone making a mistake like this very near the start of play and
only finding out about it when they close the loop at the very end. I
discuss possible improvements in a comment, but I don't think any
improvement avoids that problem completely, so I think it may just be
a form of annoyance that right-click-less players have to live with.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Loopy differs from the other recently-reworked puzzles in that it
doesn't disallow loops completely in the solution - indeed, one is
actually required! But not all loops are what you wanted, so you have
to be a bit more subtle in what you highlight as an error. And the new
findloop system doesn't make that easy, because it only answers the
question 'is this edge part of a loop?' and doesn't talk about loops
as a whole, or enumerate them.
But since I was working in this area anyway, I thought I might as well
have a think about it; and I've come up with a strategy that seems
quite sensible to me, which I describe in a big comment added in
loopy.c. In particular, the new strategy should make a more sensible
decision about whether to highlight the loop or the non-loop edges, in
cases where the user has managed to enter a loop plus some extra
stuff.
|
| |
|
|
|
|
|
|
| |
If you had a single connected path linking the source to the
destination but _also_ had a spurious edge elsewhere in the grid, then
the spurious edge would be highlighted as an error, but it wouldn't
inhibit declaring the game complete and showing the victory flash.
|
| |
|
|
|
|
|
| |
Tracks's previous loop detector was very basic, and only bothered to
highlight one loop, even if the player managed to create more than one
at a time. Now we highlight all of them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old face-dsf based loop detector is gone, and now we just call
findloop instead.
This is just a code cleanup: it doesn't fix any bugs that I know of.
In principle, it provides the same futureproofing we gained by making
the same change in Net, but Slant as a puzzle is less adaptable to
topologically interesting surfaces - in particular, you _can't_ play
it on any edgeless surface like a torus or Klein bottle, because no
filled grid can be loop-free in the first place. (The only way a
connected component can avoid having a loop surrounding it is if it
connects to the grid edge, so there has to _be_ a grid edge.) But you
could play Slant on a Mobius strip, I think, so perhaps one day...
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've removed the old algorithm (the one described as 'footpath dsf' in
the findloop.c appendix comment, though I hadn't thought of that name
at the time), and replaced it with calls to the new API.
This should have no functional effect: there weren't any known bugs in
the previous loop-finder that affected currently supported play modes.
But this generality improvement means that non-orientable playing
surfaces could be supported in the future, which would have confused
the old algorithm. And Net, being the only puzzle as yet that's played
on a torus, is perhaps the one most likely to want to generalise
further at some point.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Bridges only needs a loop detector for its non-default 'don't allow
loops' mode. But the one it had was using the graph-pruning strategy,
which means it had the dumb-bell bug - two loops joined by a path
would highlight the path as well as the loops. Switching to the new
findloop system fixes that bug.
A side effect is that I've been able to remove the 'scratch' array
from the game_state, which was only used by the old loop finder, so
that should save memory.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the course of another recent project I had occasion to read up on
Tarjan's bridge-finding algorithm. This analyses an arbitrary graph
and finds 'bridges', i.e. edges whose removal would increase the
number of connected components. This is precisely the dual problem to
error-highlighting loops in games like Slant that don't permit them,
because an edge is part of some loop if and only if it is not a
bridge.
Having understood Tarjan's algorithm, it seemed like a good idea to
actually implement it for use in these puzzles, because we've got a
long and dishonourable history of messing up the loop detection in
assorted ways and I thought it would be nice to have an actually
reliable approach without any lurking time bombs. (That history is
chronicled in a long comment at the bottom of the new source file, if
anyone is interested.)
So, findloop.c is a new piece of reusable library code. You run it
over a graph, which you provide in the form of a vertex count and a
callback function to iterate over the neighbours of each vertex, and
it fills in a data structure which you can then query to find out
whether any given edge is part of a loop in the graph or not.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
These are necessary because the argument to a ctype function cannot be
a negative value unless it's EOF. Thanks to Cygwin gcc for pointing
out the mistake, and to Patrick Shaughnessy for this patch.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
A letter offset by one from a ball on the edge should be an R, not an
H. Thanks to Kevin Buzzard for pointing out the error.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The solver's array ctx->iscratch[] is used for a completely different
purpose in the DIFF_HARD code, compared to what it's used for in
DIFF_EASY and DIFF_NORMAL. In particular, a different number of
elements of the array are used - but the code which sets up the array
was not correctly initialising all of them.
I was also unable to find any clear comment that even explained _that_
the purpose of the array was entirely different between the two cases,
let alone explaining _what_ the two purposes were. So I've written
some comments as part of this commit, which should make things a bit
less confusing next time. (Though not much, I admit.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
error: 'r2.x' may be used uninitialized in this function
Its happening when using gcc 5.3 with musl C library. its considering
the case when case falls into default and immediately after exiting
this there is a check if (r1.h > 0 && r1.w > 0) where r1 element is
used but not assigned anything.
GCC is not noticing the control flow where the initilization will
always work due to assertion call can be a function call from libc
Signed-off-by: Khem Raj <raj.khem@gmail.com>
|
| |
|
|
|
|
| |
The only situation in which it actually can't find a solution is if
the puzzle is already solved, in which case it can at least fill in
*error to say so before it returns NULL.
|
| |
|
|
| |
A user pointed out today that I hadn't actually said that!
|
| |
|
|
|
|
|
|
| |
This utility works basically the same as galaxiespicture: you feed it
a .xbm bitmap on standard input, and it constructs a game ID which
solves to exactly that image. It will pre-fill some squares if that's
necessary to resolve ambiguity, or leave the grid completely blank if
it can.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The game previously only supported numeric clues round the edge; but
if for some reason you really want a puzzle with a specific solution
bitmap and that bitmap doesn't happen to be uniquely soluble from only
its row and column counts, then this gives you a fallback approach of
pre-filling a few grid squares to resolve the ambiguities.
(This also applies if the puzzle is uniquely soluble *in principle*
but not by Pattern's limited solver - for example, Pattern has never
been able to solve 4x4:2/1/2/1/1.1/2/1/1 and still can't, but now it
can solve 4x4:2/1/2/1/1.1/2/1/1,Ap which has the hard part done for
it.)
Immutable squares are protected from modification during play, and
used as initial information by the solver.
|
| |
|
|
|
|
|
|
|
|
|
| |
The algorithm for deducing how many squares in a row could be filled
in just from the initial clue set was focusing solely on _black_
squares, and forgot that if a row has a totally empty clue square then
everything in it can be filled in as white!
Now the solver can cope with puzzles such as 3x3:/1///1/ , where it
would previously have spuriously considered that it had no idea where
to start.
|
| |
|
|
|
|
| |
The game_state now includes a pointer to a game_state_common
containing all the row and column clues, which is reference-counted
and therefore doesn't have to be physically copied in every dup_game.
|
| |
|
|
|
|
|
| |
Where facilities exist, that is. Like the approach I took with PuTTY
yesterday, Buildscr will now run a code-signing script over the binary
if you specify one in the bob config, and otherwise should fall back
to just leaving that step out.
|
| |
|
|
|
|
|
|
|
|
| |
gtk_misc_set_alignment was deprecated in GTK 3.14. But my replacement
code using gtk_label_set_{x,y}align doesn't work there, because that
function wasn't introduced until GTK 3.16, so there are two minor
versions in the middle where a third strategy is needed.
(That middle strategy doesn't permit arbitrary float alignments, but
that's OK, bceause we only actually use multiples of 0.5.)
|
| |
|
|
|
|
| |
Previously moving 1 pixel would be treated as a failed drag and not an unlock.
Now you only have to release the button somewhere on the island you started on.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A user pointed out that if you construct a 'solution' in which no clue
square has too _many_ borders but at least one has too few, and then
bring those clues up to their count by adding extra stray border lines
_inside_ a connected component (avoiding actually dividing any
component completely into two), then the game checker treats that as
solved for victory-flash purposes, on the grounds that (a) the grid is
divided into components of the right size and (b) all clues are
satisfied.
A small example is 4x4n4:22a2b2c33, with the non-solution of dividing
the grid into four 2x2 square blocks and then adding a spurious extra
edge between the two 3 clues. The old Palisade completion check would
flash for victory _at the same time_ as highlighting the spurious edge
in COL_ERROR.
Fixed by enforcing in is_solved() that every border line must separate
two distinct connected components.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The solve move stored in 'aux' by new_game_desc consists of printable
characters in the range '@' to 'O', each representing a 4-bit bitmap
of edges around a cell. But the one generated on the fly by
solve_game() was missing out the 0x40 bit and just returning
characters in the range ^@ to ^O - which would not only have been
horrible if you found such a string in a save file, but also meant
that a game with any completely borderless square would have a
solution move string terminating early due to the ^@, causing
execute_move() to reject it.
Example: ./palisade --test-solve --generate 1 5x5n5#12345-37 now
succeeds, where previously it failed an assertion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 44e2690ab loosened check_completion's idea of what made a
square count as 'having track in it' for purposes of checking
violations of the row/column counts. Unfortunately, that loosened
notion also applied to the check for the game being complete - so the
game would announce a win as soon as you had every square shaded, even
if you hadn't actually laid all the exact track positions down.
Now we separately count up the number of track-ish squares and the
number of fully completed ones, and use the former for error checking
and the latter for completion checking.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
- Count any square as having a track either if the square is marked
as such (rendered as a different background), or if at least one
adjacent edge is marked as containing a segment of train track
(rendered as train tracks if they're placed, else as an '=').
- Do the same counting in rows and columns.
|
| |
|
|
|
|
|
|
|
| |
- Mark a clue as an error if too many monsters are seen, even if
some squares are empty.
- Mark a clue as an error if too few monsters are seen, taking into
account how many more sightings are possible given the number of
empty squares and how many times each of them are visited.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Probably because I wrote a couple of loops up to the maximum cell
value using the non-idiomatic <= for their termination test, I also
managed to use <= inappropriately for iterating over every cell of the
grid, leading to a couple of references just off the end of arrays.
Amusingly, it was the Emscripten front end which pointed this out to
me by actually crashing as a result! Though valgrind found it just
fine too, once I thought to run that. But it comes to something when
running your C program in Javascript detects your memory errors :-)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous solver could cope with inferring a '1' in an empty
square, but had no deductions that would enable it to infer the
existence of a '4'-sized region in 5x3:52d5b1a5b3. The new solver can
handle that, and I've made a companion change to the clue-stripping
code so that it aims to erase whole regions where possible so as to
actually present this situation to the player.
Current testing suggests that at the smallest preset a nontrivial
ghost region comes up in about 1/3 of games, and at the largest, more
like 1/2 of games. I may yet decide to introduce a difficulty level at
which it's skewed to happen more often still and one at which it
doesn't happen at all; but for the moment, this at least gets the
basic functionality into the code.
|
| | |
|
