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.
Its absence was breaking the icon build on Ubuntu 14.04, because you
ask convert to map an image into a specific 16-colour palette, and it
does so and _then_ nonconsensually maps those colours in turn through
a colourspace transformation you didn't ask for, causing icon.pl to
fail an assertion when it finds an RGB value not in the palette.
Based on a web game I saw a few years ago, and dashed off this weekend
after I thought of a way to write a good (though not quite optimal)
heuristic solver, here's a random little thing not quite in the same
line as the most usual kind of Puzzles fare: instead of making you
scratch your head to find any move to make at all, it's easy to find
solutions in principle, and the challenge comes from having to do so
within a move limit.
'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]
in the 'unfinished' directory for a while, and has now been finished
up thanks to James Harvey putting in some effort and galvanising me to
put in the rest. This is 'Pearl', an implementation of Nikoli's 'Masyu'.
The code in Loopy that generates a random loop along grid edges to use
as the puzzle solution has been abstracted out into loopgen.[ch] so
that Pearl can use it for its puzzle solutions too. I've also
introduced a new utility module called 'tdq' (for 'to-do queue').
[originally from svn r9379]
Hitori. One infrastructure change in the process: latin.c has
acquired a utility function to generate a latin rectangle rather
than a full square.
[originally from svn r8828]
is mostly done with ifdefs in windows.c; so mkfiles.pl generates a
new makefile (Makefile.wce) and Recipe enables it, but it's hardly
any different from Makefile.vc apart from a few definitions at the
top of the files.
Currently the PocketPC build is not enabled in the build script, but
with any luck I'll be able to do so reasonably soon.
[originally from svn r7337]
supports monochrome icons, can deal with any size of image you're
mad enough to put in there, and will construct icons with whatever
combination of sizes and resolutions you feel like specifying. This
has involved a change in the command-line syntax, hence the
adjustment to Makefile.
(I don't imagine that the changes described here will be critical to
Puzzles any time soon, but I might reuse this script elsewhere and
then I won't want it to have arbitrary limitations.)
[originally from svn r7031]
instead of having the puzzle binary export its window ID to a script
which then runs xwd, we can use the gdk-pixbuf library to have the
puzzle binary _itself_ read its own internal pixmap and save it
straight to a PNG. How handy. And faster, and less timing-sensitive.
[originally from svn r7022]
mkfiles.pl change (I don't seem to be planning ahead very well this
week), this time to provide a list of fallback options for an object
file. That way, I have a no-icon.c which quietly replaces
icons/foo-icon.c if the latter doesn't exist, and so again people
checking straight out from Subversion shouldn't have trouble.
[originally from svn r7021]
Windows puzzle binaries. This checkin involves several distinct
changes:
- mkfiles.pl now has an extra feature: if an object file is listed
in Recipe with a trailing question mark, it will be considered
optional, and silently dropped from the makefile if its primary
source file isn't present at the time mkfiles.pl runs. This means
people who check out the puzzles from Subversion and just run
mkfiles.pl shouldn't get build failures; they just won't get the
icons.
- all the .R files now use this feature to include an optional
Windows resource file.
- the .rc resource source files are built by icons/Makefile.
- windows.c finds the icon if present and uses it in place of the
standard Windows application icon.
[originally from svn r7020]
the main screenshots. (A few, like Map, were perfect already.)
In the process I've vertically reflected the puzzle shown in the
Pattern save file, to bring a more interesting piece of it into the
top left corner :-)
[originally from svn r7019]
screenshots into appropriate sizes and colour depths. This is all
done with a nasty Perl script, because ImageMagick does not output
correct .ICO format. Not sure why; it isn't _that_ hard.
I intend at some point to link the resulting icons into the actual
Windows puzzle binaries, but before then I have to make them
prettier: most of them would benefit from being derived from a
smaller crop of the puzzle screenshot instead of trying to fit the
whole thing in.
[originally from svn r7017]
the web, which I hope will also end up being extended to generate
both Windows and X icons for each individual puzzle. The mechanism
is: for each puzzle there's a save file in the `icons' subdirectory
showing a game state which I think is a decent illustration of the
puzzle, and then there's a nasty set of scripts which runs each
puzzle binary, loads that save file, grabs a screenshot using xwd,
and munges it into shape.
In order to support this I've added two new options (--redo and
--windowid) to all the GTK puzzles, which I don't expect ever to be
used outside the icons makefile. I've also added two more options
(--load and --id) which force a GTK puzzle to treat its command-line
option as a save file or as a game ID respectively (the previous
behaviour was always to guess, and sometimes it guessed wrong).
[originally from svn r7014]
