applets, here's an alternative webification in Javascript, using
Emscripten in asm.js mode (so that as browsers incorporate asm.js
optimisation, the game generation should run really fast).
[originally from svn r9781]
web pages for the Java applets. Previously, those have all been
maintained by hand in my website's svn area, which is a bit silly. Now
we have a file per puzzle in the 'html' subdirectory which contains
the puzzle's name, one or two attributes, and the instructions snippet
to go below the puzzle applet; and then there's a Perl script that
builds all the real web pages out of that by adding in the parts
common across all files: the header, footer, and middle fragment with
the <applet> tag and resizing bits and pieces.
One piece _not_ checked in here is the footer text specific to my
hosting at chiark, which I think does still belong in the www area. So
Buildscr doesn't actually build the web pages; it just delivers the
bits and pieces by which my nightly snapshot script will be able to
run the program that _does_ build them, passing that footer as an
extra argument.
[originally from svn r9780]
fix in r9777 when I added documentation of the function it wistfully
imagined might one day exist.
[originally from svn r9779]
[r9777 == 1fdafb6abf2d3ea0d37e79b5dfd9daf8eed28f22]
(If you're going to memset a struct to 0 before filling in the fields
you care about, do use sizeof the struct rather than sizeof the
pointer; but also, if you're filling in _every_ field, there's no need
to bother anyway.)
[originally from svn r9773]
sprintf in both locations (screen and print) that need it. Fixes a bug
in which clues greater than 9 came out as hex digits in printed
puzzles.
[originally from svn r9765]
conditionalised on !ds->started, so that we still do all the looping
over everything even if we know it's all going to be redrawn. This is
because deciding how much needs redrawing is not the only important
thing in those loops - they also set up arrays like ds->clue_error,
which tell the individual redraw functions _what_ to draw.
Fixes a bug in which, if you start a Loopy game and make moves causing
a clue to light up red for an error and then save your game, loading
the same save file at the start of a Loopy run would fail to highlight
the erroneous clue.
(This commit diff looks large, but actually it changes almost nothing
but whitespace.)
[originally from svn r9751]
the 'completed' flag is not reset if you make a new move transforming
a solved game into an unsolved state, so the game won't flash again if
you manually erase and redraw a line segment (though it still will if
you undo and redo past the first solved state in the undo history).
[originally from svn r9750]
The Windows puzzles now accept similar command-line syntax to the GTK
ones, in that you can give them either a game ID (descriptive, random
or just plain params) or the name of a save file. Unlike the GTK ones,
however, the save file interpretation is tried first; this is because
some puzzles (e.g. Black Box) will interpret any old string as a valid
(if boring) game ID, and unlike the GTK puzzles it's not feasible to
require users to disambiguate via a command-line option, because on
Windows a thing that might easily happen is that a user passes a save
file to a puzzle binary via 'Open With' in the GUI shell, where they
don't get the chance to add extra options.
In order to make this work sensibly in the all-in-one Windows app, I
had to get round to another thing I've been planning to do for a
while, which is to write a function to examine a saved game file and
find out which puzzle it's for. So the combined Windows binary will
auto-switch to the right game if you pass a save file on its command
line, and also if you use Load while the program is running.
Another utility function I needed is one to split the WinMain single
command line string into argv. For this I've imported a copy of
split_into_argv() from Windows PuTTY (which doesn't affect this
package's list of copyright holders, since that function was all my
own code anyway).
[originally from svn r9749]
draw_numbers() was considerably confused between the width of the clue
border at the left and the height of the clue border at the top.
Unconfuse it (I think).
[originally from svn r9737]
bombing out due to an option that we don't recognise but GTK will.
Somehow my basically workable plan had been completely nullified by
putting the error check in the wrong place.
[originally from svn r9733]
gtk_widget_get_allocation conditional on GTK being new enough to have
that function.
I'm assuming until someone proves otherwise that if it isn't that new,
then it also isn't one of the versions of GTK which exhibit the bug
which that call was working around (since gtk_widget_get_allocation
came in 2.18, and the problem seems to have arisen since 2.20).
[originally from svn r9712]
Ubuntu 12.04 machine. What seems to happen is that we set up a window
containing a menu bar, a drawing area and a status bar, and set the
size of the drawing area; then the window is displayed _without_ the
menu bar; then we reduce the drawing area's size request to (1,1) to
let the user resize the window smaller; and now GTK gets round to
constructing the menu bar, and the drawing area helpfully shrinks a
bit to make room for it.
My fix is to set a 'shrink pending' flag instead of shrinking the
drawing area's size request, and defer the actual shrink operation
until the menu bar and status bar are both present.
[originally from svn r9711]
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]
'Haunted Mirror Maze', a game involving placing ghosts, zombies and
vampires in a grid so that the right numbers of them are visible along
sight-lines reflected through multiple mirrors.
[originally from svn r9652]
and Makefile.doc a command-line parameter 'BINPREFIX' which will be
prepended to all the game binary names. E.g. 'make BINPREFIX=sgt-' and
'make BINPREFIX=sgt- install', and correspondingly 'make -f
Makefile.doc BINPREFIX=sgt-'.
Also included in this commit by mistake, changes to singles.c to add
\n to the end of all its debug() statements. I meant to commit that
separately. Oops.
[originally from svn r9606]
user is already in the 'dead' state when they press it. If so, we
reveal the rest of the mines in the grid as if it were the Windows
Minesweeper 'you lose' display, which provides information showing
what the user got wrong. (Otherwise they have to repeatedly flick back
and forth between Solve and Undo if they want to work out which flag
they placed wrongly.)
If you press Solve while alive, however, the existing behaviour
remains unchanged.
(This feature was suggested by Clive Jones a couple of weeks after I
first wrote Mines, and I've finally got round to doing it!)
[originally from svn r9561]
into a string which is usually a read-only string literal. Instead,
copy each segment into writable memory as we need it, and free it
afterwards.
[originally from svn r9558]
[r9495 == d0ff371b144d4bfe3cbfb062388347c08e431393]
solver I've just modified, by forcing every game generation to be
instantly followed by an attempt to re-solve the same game
_description_ without the aux_info.
I've hacked similar changes in to midend.c several times in the last
couple of months for one reason or another, and it's about time I
arranged not to have to recompile to do it!
[originally from svn r9549]
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]
well as marking a region as wrong if it has too many squares for the
number written in it, this patch now causes a region to be marked
wrong if it has too few squares _and no liberties_, so that it can't
just be one the user is intending to enlarge later.
[originally from svn r9534]
out-of-bounds rectangle. Instead, take the intersection of the
rectangle with the window boundary and do a smaller operation on
what's left.
[originally from svn r9503]
to translate y-coordinates from the default of up-from-bottom to the
down-from-top expected by these puzzles, because it doesn't work right
on GNUstep. Instead, we run the API in its default mode (probably a
more robust choice anyway) and translate coordinates manually in the
front end.
In the process, I've separated the processButton: method into one for
mouse buttons and one for keys, since that was the easiest way to
ensure the coordinates passed to the mid-end for the latter are -1,-1
_after_ translation rather than before.
[originally from svn r9502]
front end using GNUstep, yielding a Unix program built from the same
code. Should make it easier to check OS X behaviour without having to
move as far as a Mac :-) However, it doesn't compile as is, so I'll
apply fixes to the code until it does.
[originally from svn r9498]
