This is a combination of PuTTY r10142 and the relevant pieces of
r10141: we now enable the 'subdir-objects' mode in Makefile.am, and
stop using $(subdir) in source file paths.
(As a consequence of the latter the automake machinery now cannot live
anywhere but at the top level of the source tree, but since that's
where it was already, this is less of an upheaval here than it was for
PuTTY!)
[originally from svn r10146]
[r10141 == a947c49bec36957cb5d38e1dc2e22dc0e3465849 in putty repository]
[r10142 == 0da225829234744b1141aea3a7c54ad7d74679a7 in putty repository]
Now they're centred within the spare grid cell at the top of the
playing area, rather than being too far down so that the bottoms of
the monster drawings collide with the background of the path clues at
large magnification. Also, while I'm here, I've simplified the code
that draws the monster counts, by moving duplicated parts out of the
branches of the 'if'.
(In fact, almost all of this patch is cleanup; the only substantive
change is the one that changes dy from TILESIZE/2 to TILESIZE/4.)
[originally from svn r10108]
When you drag group elements around, previous dividers are meant to
dissolve whenever the same two elements are no longer on each side of
it. One case in which this didn't happen was that of dragging an
element from the left of a divider to the far right column - the
divider became invisible, but would then startlingly reappear if you
drag that element back to the left of whatever it was left of before.
[originally from svn r10051]
zero to be generated as the empty string rather than "0". Instead, do
the job by the obvious approach of not calling sprintf at all if the
number is zero. Works around a bug in Emscripten's C library, whose
sprintf doesn't correctly handle that corner case.
[originally from svn r9893]
flags if gcc is in use - but _only_ if they don't lead to problems in
a test compile which includes all the system and GTK headers I'm going
to want. Ubuntu 13.04 includes a version of Pango which breaks at
-Werror -pedantic, so I can't unconditionally enable all the warning
flags I might want without breaking the build in ways beyond my
control.
[originally from svn r9888]
Makefile.am, and there's a new mkauto.sh which builds a corresponding
configure script.
The old makefile has been renamed from 'Makefile' to 'Makefile.gtk',
indicating that the intended new _default_ approach is to use the
autoconf world. Makefile.gtk is provided as an emergency fallback in
case anything fails with the new stuff that used to work with it.
The new configure script does not support the same $(BINPREFIX) system
as the old Makefile did. However, as I understand it, it should be
possible to configure using --program-prefix="sgt-" (for example) and
then the binaries should all be renamed appropriately at install time.
The Makefile.am is quite painful. The Puzzles codebase relies heavily
on compiling individual object files multiple times with different the
cpp flags per build deliverable (program or library) and not per
source file. Solution: anything built with non-default compile options
has to go in its own little library. But that doesn't work either in
the general case, because as soon as you have more than one such
library linked into an application, Unix ld semantics bite you if the
objects in the libraries both refer to each other. So I ended up
building all those little libraries but not _using_ them - instead the
link commands for the programs needing those objects refer to the
objects directly, under the silly names that automake gives them.
(That's less fragile than it sounds, because it does _document_ the
names of the intermediate object files. But still, yuck.)
[originally from svn r9886]
immediate intention is to run this locally so that my XFCE main menu
acquires shortcuts for my locally compiled puzzle binaries, but I
expect the script could probably be adapted for systemwide
distribution use if any distribution hasn't already done this job in
their own way by now.
[originally from svn r9859]
to it giving each game's "internal" name (as seen in the source file,
.R etc) and also a brief description of the game. The idea of the
latter is that it should be usable as a comment field in .desktop
files and similar.
[originally from svn r9858]
happening was that at the point of calling grid_make_consistent, the
grid had no faces or vertices, probably because grid_trim_vigorously
had removed them all, causing grid_make_consistent to try to allocate
a negative amount of memory and die in snewn.
Fixed by detecting this case in new_desc_penrose and retrying until
generation is successful. (It wasn't happening 100% of the time, just
_most_ of the time.) The same verification step is also used in
validate_desc_penrose in case a user manages to manually construct a
set of parameters leading to this failure mode.
[originally from svn r9840]
rows are permitted to have exactly the same pattern, and likewise
columns. (A row and a column can match, though.) This rule is
sometimes used, but not always; http://www.binarypuzzle.com/ in
particular has it (as a user just pointed out).
Since the filled-grid-generation stage of Unruly is implemented by
repeatedly choosing a square and then calling the solver to fill in
all its consequences, simply adding a solver mode conditional on this
flag is sufficient to do the whole of the interesting part of the job.
[originally from svn r9837]
puzzle backend function which ought to have it, and propagate those
consts through to per-puzzle subroutines as needed.
I've recently had to do that to a few specific parameters which were
being misused by particular puzzles (r9657, r9830), which suggests
that it's probably a good idea to do the whole lot pre-emptively
before the next such problem shows up.
[originally from svn r9832]
[r9657 == 3b250baa02a7332510685948bf17576c397b8ceb]
[r9830 == 0b93de904a98f119b1a95d3a53029f1ed4bfb9b3]
solve_game() was returning its aux parameter un-dupstr()ed, which is
wrong. Also clarified the developer docs on that function to make it
clearer that the returned string should be dynamic.
[originally from svn r9831]
new_desc. Oddities in the 'make test' output brought to my attention
that a few puzzles have been modifying their input game_params for
various reasons; they shouldn't do that, because that's the
game_params held permanently by the midend and it will affect
subsequent game generations if they modify it. So now those arguments
are const, and all the games which previously modified their
game_params now take a copy and modify that instead.
[originally from svn r9830]
do_recurse() now prunes early whenever it encounters a branch of the
search tree inconsistent with existing grid data (rather than the
previous naive approach of proceeding to enumerate all possibilities
anyway and then ruling them out one by one); do_recurse also tries to
split the row up into independent sections where possible; finally the
main solver loop (all three copies of which have now been factored out
into a new solve_puzzle function), instead of simply looping round and
round over all the rows and columns, heuristically looks at the ones
most changed since the last time deduction was attempted on them, on
the basis that that will probably yield the most information the
fastest.
[originally from svn r9828]
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]
