I've removed the old algorithm (the one described as 'footpath dsf' in the findloop.c appendix comment, though I hadn't thought of that name at the time), and replaced it with calls to the new API. This should have no functional effect: there weren't any known bugs in the previous loop-finder that affected currently supported play modes. But this generality improvement means that non-orientable playing surfaces could be supported in the future, which would have confused the old algorithm. And Net, being the only puzzle as yet that's played on a torus, is perhaps the one most likely to want to generalise further at some point.
More sensible to bring all the pieces of per-puzzle descriptive text together into one place, so they can be easily reused everywhere they're needed.
install the actual games, not the auxiliary binaries or nullgame. [originally from svn r9887]
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]
defining it centrally per port, I think it's neater to define it for each puzzle when adding that puzzle to the ALL list - because those front ends which take -DCOMBINED are precisely those which use ALL. In particular, this change opens up the possibility of compiling both individual puzzles _and_ a combined monolith within the same makefile. [originally from svn r8178]
This means that puzzles.rc2 is always included in all Windows and PocketPC builds, which in turn means that I should be able to start filling it full of VERSIONINFO and have that reliably included as well. [originally from svn r7339]
[originally from svn r7319]
infrastructure to the mkfiles.pl framework for the convenience of the build script: it generates `wingames.lst', a list of the Windows binaries which are ship-worthy games as opposed to nullgame or command-line auxiliary programs. [originally from svn r7206]
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]