blocks, because 'make test' showed up very large blocks as an
occasional slowdown factor in game generation (takes too long to
iterate over all possibilities). This is a good idea in any case,
because really big multiplicative clue numbers have trouble fitting in
the square.
[originally from svn r9827]
not only enumerating all possible arrangements of monsters along a
sight-line in O(3^n) time, but also allocated memory for them all and
then does a quadratic-time loop over that list to find arrangements
with a unique visibility count from both ends. Spotted by the new
'make test', which observed that 7x7dn#517035041807425 took 45 seconds
to generate.
This revised version still does the initial O(3^n) enumeration, which
can probably be got rid of as well with a bit more thought, but it now
doesn't allocate nearly so much memory and it spots uniques
efficiently. The above random seed now generates the same game ID in
less than a second, which drops this puzzle off the 'make test' hit
list of things most obviously needing speedup.
[originally from svn r9826]
the GTK front end, plus a 'make test' target in the GTK makefile which
uses them to automatically generate 100 puzzles for each game at each
preset configuration, test-run them back through the solver without
their aux_info to ensure that can cope, and produce an HTML box plot
of game generation times for each preset.
As part of this work I've removed the TESTSOLVE mechanism from r9549,
since the new --test-solve option does the same thing better (in that
when something goes wrong it prints the random seed that caused the
problem).
[originally from svn r9825]
[r9549 == 5a095b8a08fa9f087b93c86aea0fa027138b028d]
meaning to revisit for a while. The new version generates more nicely
symmetric grids (best at even heights, but still improved even at odd
heights), and avoids any 'ears' on the grid (triangles at the corners
connected to only one other triangle, which tend to be boringly easy
places to start solving).
I've reused the grid-description-string mechanism invented for the
Penrose tilings as a versioning mechanism for the triangular grids, so
that old game descriptions should still be valid, and new triangular-
grid game descriptions begin with an "0_" prefix to indicate that they
are based on the new-style construction.
[originally from svn r9824]
defined the same way and used to draw the normal background of the
puzzle, but there's a new slightly darker COL_SYSBACKGROUND which is
not used for anything at all in the puzzle backend but which occupies
colour slot #0 so that the system will use it to fill around the
playable area if the puzzle is imprecisely resized.
This doesn't _sensibly fix_ the annoyance in Untangle where a non-
square window gives rise to unusable dead space, but it at least works
around it by making the dead space obviously something to stay away
from.
[originally from svn r9823]
Rather than design an ersatz 'window frame' surrounding the puzzle
canvas, I've simply overlaid the resize handle on the corner of the
puzzle itself (canvas or status bar, depending on whether the latter
exists), trusting that all games in my collection provide a reasonable
border within their drawing area. (OS X already does this with its
resize handle, so it's not as if there's no precedent.)
Unlike the desktop versions, I control the resize behaviour completely
in this environment, so I can constrain the canvas to only ever be
sensible sizes with no dead space round the edges (and, in particular,
preserve the aspect ratio).
Right-clicking the resize handle will restore the puzzle's default
tile size. I had intended to implement a maximise-to-browser-window
button too, but was annoyingly foiled by scrollbars - if you maximise
to the current window width, and as a result the text below the puzzle
scrolls off the bottom, then a vertical scrollbar appears and eats
into the width you just maximised to. Gah.
[originally from svn r9822]
inside the top-level display:none puzzle container as a side effect of
r9809.
Also, while I'm at it, reword the apology to mention typed arrays as
the most likely cause of failure (AFAIK that's the most modern feature
required by the JS front end), and fix indecision between singular and
plural ('this puzzle' doesn't work, perhaps a feature 'they depend on'
is missing).
[originally from svn r9818]
[r9809 == 5dc559c8be1b8f6ed15f560433f25c952c874f93]
the game-type <select>, since IE turns out to ignore display:none on
options. Oh well.
Instead I now do a more transparent thing: when custom game params are
in use, there's a "Custom" option selected in the dropdown, and a
separate 'Re-customise' option which brings the config box back up.
When an ordinary preset is selected, the Custom option is missing, and
there's just a 'Customise'.
In the process I've tinkered a bit to arrange that the custom 'preset'
is always represented by a negative number rather than one past the
last real preset; that seems more consistent overall.
[originally from svn r9811]
Unlike Firefox, IE and Chrome don't generate keypress events at all if
you suppress the default handling of keydowns. Therefore, we have to
figure out everything from the keydown event, because if we unsuppress
the default handling of any keydowns then we'll get annoyances like ^R
going back to meaning reload-page rather than redo-move.
[originally from svn r9810]
added a trivial doctype (IE complained without it), but that caused a
gap to appear between the puzzle and the status bar, so I tinkered a
bit more and ended up removing the <table> completely (no great loss)
as well as adding display:block to the canvas and explicitly setting
the width of not only the status bar div but also its parent div.
Meanwhile, I'm putting the "px" on the end of a lot of properties I
set from JS, because IE complains about that too if I don't.
[originally from svn r9809]
the return value of relative_mouse_coords! I only got away with that
error because the canvas was at offset zero compared to its immediate
parent element.
[originally from svn r9808]
when the user pressed 'n' for a new game, because all the front end
knows is that it passed a keystroke to the puzzle, and it has no way
of hearing back that a particular keypress resulted in a game id
change.
To fix this, I've renamed midend_request_desc_changes to
midend_request_id_changes and expanded its remit to cover _any_ change
to the game ids. So now that callback in the Emscripten front end is
the only place from which update_permalinks is called (apart from
initialising them at setup time), and that should handle everything.
[originally from svn r9805]
didn't like them, which doesn't matter as such since they won't run
these JS puzzles anyway (no TypedArray support) but it hints that
other JS implementations might be picky about this too.
[originally from svn r9804]
mention that the HTML pages generated by html/jspage.pl are also an
integral part of this front end. (The NestedVM frontend is more
self-contained, needing only an appropriate <applet> tag, but this one
expects quite a few components to exist on the page and have the right
ids.)
[originally from svn r9803]
puzzle startup. The puzzle web pages now enclose the whole puzzle
(buttons, canvas, permalinks) in a div set to display:none, and
instead display an apologetic message saying 'sorry, it didn't work';
then, if we get through the whole init function without crashing, we
show the puzzle and hide the apology.
[originally from svn r9802]
The previous version dealt adequately with rectangles _partially_
overlapping the edge of the canvas, but doesn't correctly handle a
rectangle that's completely out of bounds in one direction. Replace
with a complete rewrite which is more easily seen to be correct. Also,
while I'm at it, add a missing condition to draw_update() so that we
don't even bother calling the Javascript half of it on any rectangle
that's been trimmed into nonexistence.
[originally from svn r9800]
with a trailing "..." to hint that it opens a further dialog box.
However, the _invisible_ Custom option is merely indicating what you
_do_ have selected, so we leave that one as it is. (So now they're no
longer exact twins of each other, of course.)
[originally from svn r9796]
rectangle, which showed up on the Javascript front end since the JS
canvas doesn't start out defaulting to COL_BACKGROUND. Fixed it to
draw_update to the edge of its area, and while I'm at it, narrowed the
border (since this proves we didn't really need that much space
anyway).
[originally from svn r9795]
selected. Previously we were leaving the first element on the list
selected, which is _usually_ right, but not right for Slant.
In the process of doing this, I've also reorganised to fix a crash
which shows up with non-configurable games (admittedly currently only
Nullgame :-) when we still try to call js_select_preset in spite of
not having any preset options to select.
[originally from svn r9794]
can trigger a call to a front end notification function. Use this to
update the game ID permalink when Mines supersedes its game ID.
[originally from svn r9793]
as "1" rather than "round". Must have had my Postscript brain in,
and/or been confused by lineWidth = "1" just beforehand. This fixes a
display glitch in Towers, where there's a tiny spike at the top left
corner of each tower due to a very sharp mitred line join.
[originally from svn r9791]
Javascript-side blitter creation function had forgotten to return the
new blitter's id, so the C code was still trying to use blitter #0
after it had been thrown away and replaced.
[originally from svn r9790]
type dropdown, we still get an 'onchange' event if they select it a
second time. Normally this wouldn't happen, because onchange means
what it says and we only get it if a _different_ element is selected.
My solution is to create two list items called Custom, set one of them
as display:none to stop it showing up when the list is dropped down,
and to select it after the configuration box closes.
[originally from svn r9788]
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]
