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.
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.
Jonas Kölker points out that commit a800ff16b (which fixed a bug in
the previous attempt) left in another bug: if the puzzle size was
changed while the window was maximised, the system would fail to
recompute the tile size and would redraw completely wrongly.
So it's not optional after all to run midend_size(), even if the
drawing area size hasn't changed. I've reverted that code to be
unconditional, and now only the refresh of the Cairo-side backing
store system is conditionalised - and that's conditionalised on
changes to either the size of the actual window _or_ the size of the
contained pixmap. (The latter should defend against redraw failure in
the case where the puzzle aspect ratio changes, so that neither the
window size nor the tile size changes but a recentre is still needed.)
I _think_ this now fixes all the cases of resizing: this time I've
tested making an unmaximised puzzle window bigger or smaller, and
within a maximised window, forcing the puzzle to scale up, scale down,
or change its aspect ratio without changing its tile size. All work,
on GTK2 and GTK3, and yet we still don't get the visible flicker on
status line updates that was the reason I started fiddling with this
code in the first place.
(We _do_ still call configure_area on every update of the status line,
at least under GTK3; that's going to cause a forced full redraw on
every timer tick in Mines, which is wasteful of CPU, so it would still
be nice to find a better way of identifying the cases in which no
resizing at all was necessary and we could avoid renewing the game
drawstate. But the current code at least doesn't have any display
_errors_ that I know of, which is an improvement on its previous
state.)
- Lay bridges (crosess) with Control-arrow (Shift-arrow)
- Jump (non-orthogonally) to nearby islands with number keys, a..f
- Mark islands as done with a single tap on the space bar
- The file selector for loading and saving gets a g_free().
- The handling of saving (menu_save_event) gets an sfree().
- It's also slightly restructured to prevent future errors.
- menu_load_event was already structured to prevent this error.
- The OLD_FILESEL code seems to not need a g_free().
Position the cursor in the top (bottom) row, press enter and press up
(down). The game acts as if you had pressed right, both with Enter-
and Space-based dragging.
Pressing Ctrl-arrow or Shift-arrow on a tile now moves the row or
column under the tile. With Ctrl, the cursor moves as well so you can
keep making moves that affect the same tile; with Shift, the cursor
stays put so you can keep making moves that affect the same location.
These button codes are generated by the back/forward button pair on
the sides of some mice, and web browsers treat these as the back and
forward actions in the page history.
Pressing H now suggests the lexicographically first row consistent
with all previous feedback.
The previous function of the H key to toggle a hold marker on the
current peg is now performed by Space / CURSOR_SELECT2, which is more
in line with other puzzles anyway.
Recall that the hint feature is really an incremental solver. Apply
it repeatedly until the board is solved. Grade puzzles as solvable
or unsolvable by checking their parity.
This is really an incremental solver. It alternates between solving
rows and solving columns. Each row and column is solved one piece at
a time. Except for some temporary trickery with the last two pieces
in a row or column, once a piece is solved it is never moved again.
(On non-square grids it first solves some rows or some columns until
the unsolved part is a square, then starts alternating.)
Net provides the best demonstration of why. Complete a game of net,
then press N while the victory flash is playing: then the victory
flash keeps playing on the new game board. (Tip: save a game which
but for a redo is completed, then you can reproduce this repeatedly
without having to complete a new game each time.)
The flash timer reset code is placed together with the animation
timer reset code, because the two are conceptually related. Note
that midend_restart_game resets animations via midend_finish_move.
This is already done in midend_restart_game via midend_finish_move.
If it's good enough for restarting a game, it ought to also be good
enough for starting new games.
Restarting a game that is already in the restarted state is meant to
be a no-op. It stopped animations. Don't do this.
Also, given that midmidend_restart_game called midend_stop_anim
twice, the invocation we remove was redundant.
Animations were stopped if a new game was initiated with a keyboard
shortcut (n, N, Ctrl-N), but not via menu items such as presets or
custom configurations, nor (perhaps not a problem) on starting the
program. Fix this, so that animations are stopped on a new game no
matter how the new game is started.
It's becoming annoying to keep working within the increasing
restrictions on GtkDialog, in particular the fact that not only do we
have to let it have complete control of the button area, but also it's
not clear whether we can intercept a press of the 'OK' button and
display an error message rather than ending the dialog.
So, as I did in PuTTY, I'm resorting to using an ordinary GtkWindow
with controls I laid out myself.
This is a lot easier than faffing about setting up a dialog box
ourself, and also avoids direct access to GtkDialog's action area
(deprecated in GTK 3.16).
Highlight clues of value n in Towers if its row/column contains an
increasing sequence of length n, the last number of which is not equal
to the number of rows/columns (i.e. such that the sequence will have
to be extended, in violation of the clue).
Commit 8b491946e had a bug: configure_area stopped doing most of its
work if the new size already matched fe->w and fe->h, but in fact the
GTK2 resize_fe() _already_ set up fe->w and fe->h for the new size. I
managed not to notice, because I checked it all worked on GTK 3 but
only tested resizing to a _smaller_ puzzle on GTK 2. Ahem.
Now we don't change fe->w and fe->h at all until configure_area is
called. Also, we initialise them to dummy values at setup time, so
that configure_area won't compare the new size with uninitialised
data.
