From 6ed88c8a6f1468c04eef9cc0a63f582fd3942c05 Mon Sep 17 00:00:00 2001 From: Ben Hutchings Date: Sun, 2 Nov 2008 19:14:58 +0000 Subject: [PATCH] puzzles-r6526.tar.gz --- CHECKLST.txt | 47 - HACKING | 4287 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Makefile | 304 +++++ Makefile.cyg | 335 +++++ Makefile.osx | 203 +++ Makefile.vc | 484 +++++++ makedist.sh | 57 - manifest | 63 + puzzles.but | 2 +- puzzles.cnt | 107 ++ puzzles.hlp | Bin 0 -> 128694 bytes puzzles.txt | 1943 ++++++++++++++++++++++++++ version.def | 1 + 13 files changed, 7728 insertions(+), 105 deletions(-) delete mode 100644 CHECKLST.txt create mode 100644 HACKING create mode 100644 Makefile create mode 100644 Makefile.cyg create mode 100644 Makefile.osx create mode 100644 Makefile.vc delete mode 100755 makedist.sh create mode 100644 manifest create mode 100644 puzzles.cnt create mode 100644 puzzles.hlp create mode 100644 puzzles.txt create mode 100644 version.def diff --git a/CHECKLST.txt b/CHECKLST.txt deleted file mode 100644 index 38dd16c..0000000 --- a/CHECKLST.txt +++ /dev/null @@ -1,47 +0,0 @@ -Useful checklists -================= - -Things to remember when adding a new puzzle -------------------------------------------- - -Write the source file for the new puzzle (duhh). - -Add it to Recipe in _four_ places: - - the `ALL' definition, to ensure it is compiled into the OS X binary - - as a GTK build target - - as a Windows build target - - in the Unix `make install' section at the bottom. - -If the puzzle is by a new author, modify the copyright notice in -LICENCE and in puzzles.but. (Also in index.html, but that's listed -below under website changes.) - -Add it to list.c so that the OS X binary will be able to select it -from the menus. (Also, double-check that the game structure name in -the source file has been renamed from `nullgame'. Actually compiling -it on OS X would be a good way to check this, if convenient.) - -Add a documentation section in puzzles.but. - -Make sure there's a Windows help topic name defined in puzzles.but, -and that it's referenced by the help topic field in the game -structure in the source file. - -Add the new Unix binary name to the svn:ignore property. - -Don't forget to `svn add' the new source file before checkin! - -Put the puzzle on the web: - - make a screenshot - - add an entry in the puzzles list in index.html - - adjust the copyright in index.html if the puzzle is by a new - author - - add a link to the Windows binary - - make sure the Windows binary link points at the right binary, not - the wrong one! - - run puzzlesnap - - test that the binary link and the docs link work - - run webupdate - - test again - - `svn add' the binary symlink and the screenshot - - check in the website changes (screenshot, symlink, index.html) diff --git a/HACKING b/HACKING new file mode 100644 index 0000000..a0fe87d --- /dev/null +++ b/HACKING @@ -0,0 +1,4287 @@ +Developer documentation for Simon Tatham's puzzle collection +============================================================ + +This is a guide to the internal structure of Simon Tatham's Portable +Puzzle Collection (henceforth referred to simply as `Puzzles'), for +use by anyone attempting to implement a new puzzle or port to a new +platform. + +This guide is believed correct as of r6190. Hopefully it will be updated +along with the code in future, but if not, I've at least left this +version number in here so you can figure out what's changed by tracking +commit comments from there onwards. + +1. Introduction +--------------- + +The Puzzles code base is divided into four parts: a set of +interchangeable front ends, a set of interchangeable back ends, a +universal `middle end' which acts as a buffer between the two, and a +bunch of miscellaneous utility functions. In the following sections I +give some general discussion of each of these parts. + +1.1. Front end +-------------- + +The front end is the non-portable part of the code: it's the bit that +you replace completely when you port to a different platform. So it's +responsible for all system calls, all GUI interaction, and anything else +platform-specific. + +The current front ends in the main code base are for Windows, GTK and +MacOS X; I also know of a third-party front end for PalmOS. + +The front end contains main() or the local platform's equivalent. Top- +level control over the application's execution flow belongs to the front +end (it isn't, for example, a set of functions called by a universal +main() somewhere else). + +The front end has complete freedom to design the GUI for any given +port of Puzzles. There is no centralised mechanism for maintaining the +menu layout, for example. This has a cost in consistency (when I _do_ +want the same menu layout on more than one platform, I have to edit +two pieces of code in parallel every time I make a change), but the +advantage is that local GUI conventions can be conformed to and local +constraints adapted to. For example, MacOS X has strict human interface +guidelines which specify a different menu layout from the one I've used +on Windows and GTK; there's nothing stopping the OS X front end from +providing a menu layout consistent with those guidelines. + +Although the front end is mostly caller rather than the callee in its +interactions with other parts of the code, it is required to implement +a small API for other modules to call, mostly of drawing functions for +games to use when drawing their graphics. The drawing API is documented +in chapter 3; the other miscellaneous front end API functions are +documented in section 4.25. + +1.2. Back end +------------- + +A `back end', in this collection, is synonymous with a `puzzle'. Each +back end implements a different game. + +At the top level, a back end is simply a data structure, containing a +few constants (flag words, preferred pixel size) and a large number of +function pointers. Back ends are almost invariably callee rather than +caller, which means there's a limitation on what a back end can do on +its own initiative. + +The persistent state in a back end is divided into a number of data +structures, which are used for different purposes and therefore likely +to be switched around, changed without notice, and otherwise updated by +the rest of the code. It is important when designing a back end to put +the right pieces of data into the right structures, or standard midend- +provided features (such as Undo) may fail to work. + +The functions and variables provided in the back end data structure are +documented in chapter 2. + +1.3. Middle end +--------------- + +Puzzles has a single and universal `middle end'. This code is common to +all platforms and all games; it sits in between the front end and the +back end and provides standard functionality everywhere. + +People adding new back ends or new front ends should generally not need +to edit the middle end. On rare occasions there might be a change that +can be made to the middle end to permit a new game to do something not +currently anticipated by the middle end's present design; however, this +is terribly easy to get wrong and should probably not be undertaken +without consulting the primary maintainer (me). Patch submissions +containing unannounced mid-end changes will be treated on their merits +like any other patch; this is just a friendly warning that mid-end +changes will need quite a lot of merits to make them acceptable. + +Functionality provided by the mid-end includes: + + - Maintaining a list of game state structures and moving back and + forth along that list to provide Undo and Redo. + + - Handling timers (for move animations, flashes on completion, and in + some cases actually timing the game). + + - Handling the container format of game IDs: receiving them, picking + them apart into parameters, description and/or random seed, and + so on. The game back end need only handle the individual parts + of a game ID (encoded parameters and encoded game description); + everything else is handled centrally by the mid-end. + + - Handling standard keystrokes and menu commands, such as `New Game', + `Restart Game' and `Quit'. + + - Pre-processing mouse events so that the game back ends can rely on + them arriving in a sensible order (no missing button-release events, + no sudden changes of which button is currently pressed, etc). + + - Handling the dialog boxes which ask the user for a game ID. + + - Handling serialisation of entire games (for loading and saving a + half-finished game to a disk file, or for handling application + shutdown and restart on platforms such as PalmOS where state is + expected to be saved). + +Thus, there's a lot of work done once by the mid-end so that individual +back ends don't have to worry about it. All the back end has to do is +cooperate in ensuring the mid-end can do its work properly. + +The API of functions provided by the mid-end to be called by the front +end is documented in chapter 4. + +1.4. Miscellaneous utilities +---------------------------- + +In addition to these three major structural components, the Puzzles code +also contains a variety of utility modules usable by all of the above +components. There is a set of functions to provide platform-independent +random number generation; functions to make memory allocation easier; +functions which implement a balanced tree structure to be used as +necessary in complex algorithms; and a few other miscellaneous +functions. All of these are documented in chapter 5. + +1.5. Structure of this guide +---------------------------- + +There are a number of function call interfaces within Puzzles, and this +guide will discuss each one in a chapter of its own. After that, there +will be a section about how to design new games, with some general +design thoughts and tips. + +2. Interface to the back end +---------------------------- + +This chapter gives a detailed discussion of the interface that each back +end must implement. + +At the top level, each back end source file exports a single global +symbol, which is a `const struct game' containing a large number of +function pointers and a small amount of constant data. This structure is +called by different names depending on what kind of platform the puzzle +set is being compiled on: + + - On platforms such as Windows and GTK, which build a separate binary + for each puzzle, the game structure in every back end has the same + name, `thegame'; the front end refers directly to this name, so that + compiling the same front end module against a different back end + module builds a different puzzle. + + - On platforms such as MacOS X and PalmOS, which build all the puzzles + into a single monolithic binary, the game structure in each back end + must have a different name, and there's a helper module `list.c' + which contains a complete list of those game structures. + +On the latter type of platform, source files may assume that the +preprocessor symbol `COMBINED' has been defined. Thus, the usual code to +declare the game structure looks something like this: + + #ifdef COMBINED + #define thegame net /* or whatever this game is called */ + #endif + + const struct game thegame = { + /* lots of structure initialisation in here */ + }; + +Game back ends must also internally define a number of data structures, +for storing their various persistent state. This chapter will first +discuss the nature and use of those structures, and then go on to give +details of every element of the game structure. + +2.1. Data structures +-------------------- + +Each game is required to define four separate data structures. This +section discusses each one and suggests what sorts of things need to be +put in it. + +2.1.1. `game_params' +-------------------- + +The `game_params' structure contains anything which affects the +automatic generation of new puzzles. So if puzzle generation is +parametrised in any way, those parameters need to be stored in +`game_params'. + +Most puzzles currently in this collection are played on a grid of +squares, meaning that the most obvious parameter is the grid size. Many +puzzles have additional parameters; for example, Mines allows you to +control the number of mines in the grid independently of its size, Net +can be wrapping or non-wrapping, Solo has difficulty levels and symmetry +settings, and so on. + +A simple rule for deciding whether a data item needs to go in +`game_params' is: would the user expect to be able to control this data +item from either the preset-game-types menu or the `Custom' game type +configuration? If so, it's part of `game_params'. + +`game_params' structures are permitted to contain pointers to subsidiary +data if they need to. The back end is required to provide functions to +create and destroy `game_params', and those functions can allocate and +free additional memory if necessary. (It has not yet been necessary to +do this in any puzzle so far, but the capability is there just in case.) + +`game_params' is also the only structure which the game's compute_size() +function may refer to; this means that any aspect of the game which +affects the size of the window it needs to be drawn in must be stored in +`game_params'. In particular, this imposes the fundamental limitation +that random game generation may not have a random effect on the window +size: game generation algorithms are constrained to work by starting +from the grid size rather than generating it as an emergent phenomenon. +(Although this is a restriction in theory, it has not yet seemed to be a +problem.) + +2.1.2. `game_state' +------------------- + +While the user is actually playing a puzzle, the `game_state' structure +stores all the data corresponding to the current state of play. + +The mid-end keeps `game_state's in a list, and adds to the list every +time the player makes a move; the Undo and Redo functions step back and +forth through that list. + +Therefore, a good means of deciding whether a data item needs to go in +`game_state' is: would a player expect that data item to be restored on +undo? If so, put it in `game_state', and this will automatically happen +without you having to lift a finger. If not - for example, the deaths +counter in Mines is precisely something that does _not_ want to be reset +to its previous state on an undo - then you might have found a data item +that needs to go in `game_ui' instead. + +During play, `game_state's are often passed around without an +accompanying `game_params' structure. Therefore, any information in +`game_params' which is important during play (such as the grid size) +must be duplicated within the `game_state'. One simple method of doing +this is to have the `game_state' structure _contain_ a `game_params' +structure as one of its members, although this isn't obligatory if you +prefer to do it another way. + +2.1.3. `game_drawstate' +----------------------- + +`game_drawstate' carries persistent state relating to the current +graphical contents of the puzzle window. The same `game_drawstate' +is passed to every call to the game redraw function, so that it can +remember what it has already drawn and what needs redrawing. + +A typical use for a `game_drawstate' is to have an array mirroring the +array of grid squares in the `game_state'; then every time the redraw +function was passed a `game_state', it would loop over all the squares, +and physically redraw any whose description in the `game_state' (i.e. +what the square needs to look like when the redraw is completed) did +not match its description in the `game_drawstate' (i.e. what the square +currently looks like). + +`game_drawstate' is occasionally completely torn down and reconstructed +by the mid-end, if the user somehow forces a full redraw. Therefore, no +data should be stored in `game_drawstate' which is _not_ related to the +state of the puzzle window, because it might be unexpectedly destroyed. + +The back end provides functions to create and destroy `game_drawstate', +which means it can contain pointers to subsidiary allocated data if it +needs to. A common thing to want to allocate in a `game_drawstate' is a +`blitter'; see section 3.1.11 for more on this subject. + +2.1.4. `game_ui' +---------------- + +`game_ui' contains whatever doesn't fit into the above three structures! + +A new `game_ui' is created when the user begins playing a new instance +of a puzzle (i.e. during `New Game' or after entering a game ID etc). It +persists until the user finishes playing that game and begins another +one (or closes the window); in particular, `Restart Game' does _not_ +destroy the `game_ui'. + +`game_ui' is useful for implementing user-interface state which is not +part of `game_state'. Common examples are keyboard control (you wouldn't +want to have to separately Undo through every cursor motion) and mouse +dragging. See section 6.3.2 and section 6.3.3, respectively, for more +details. + +Another use for `game_ui' is to store highly persistent data such as +the Mines death counter. This is conceptually rather different: where +the Net cursor position was _not important enough_ to preserve for the +player to restore by Undo, the Mines death counter is _too important_ to +permit the player to revert by Undo! + +A final use for `game_ui' is to pass information to the redraw function +about recent changes to the game state. This is used in Mines, for +example, to indicate whether a requested `flash' should be a white flash +for victory or a red flash for defeat; see section 6.3.5. + +2.2. Simple data in the back end +-------------------------------- + +In this section I begin to discuss each individual element in the back +end structure. To begin with, here are some simple self-contained data +elements. + +2.2.1. `name' +------------- + + const char *name; + +This is a simple ASCII string giving the name of the puzzle. This name +will be used in window titles, in game selection menus on monolithic +platforms, and anywhere else that the front end needs to know the name +of a game. + +2.2.2. `winhelp_topic' +---------------------- + + const char *winhelp_topic; + +This member is used on Windows only, to provide online help. Although +the Windows front end provides a separate binary for each puzzle, it has +a single monolithic help file; so when a user selects `Help' from the +menu, the program needs to open the help file and jump to the chapter +describing that particular puzzle. + +Therefore, each chapter in `puzzles.but' is labelled with a _help topic_ +name, similar to this: + + \cfg{winhelp-topic}{games.net} + +And then the corresponding game back end encodes the topic string (here +`games.net') in the `winhelp_topic' element of the game structure. + +2.3. Handling game parameter sets +--------------------------------- + +In this section I present the various functions which handle the +`game_params' structure. + +2.3.1. default_params() +----------------------- + + game_params *(*default_params)(void); + +This function allocates a new `game_params' structure, fills it with the +default values, and returns a pointer to it. + +2.3.2. fetch_preset() +--------------------- + + int (*fetch_preset)(int i, char **name, game_params **params); + +This function is used to populate the `Type' menu, which provides a list +of conveniently accessible preset parameters for most games. + +The function is called with `i' equal to the index of the preset +required (numbering from zero). It returns FALSE if that preset does +not exist (if `i' is less than zero or greater than the largest preset +index). Otherwise, it sets `*params' to point at a newly allocated +`game_params' structure containing the preset information, sets `*name' +to point at a newly allocated C string containing the preset title (to +go on the `Type' menu), and returns TRUE. + +If the game does not wish to support any presets at all, this function +is permitted to return FALSE always. + +2.3.3. encode_params() +---------------------- + + char *(*encode_params)(game_params *params, int full); + +The job of this function is to take a `game_params', and encode it in +a string form for use in game IDs. The return value must be a newly +allocated C string, and _must_ not contain a colon or a hash (since +those characters are used to mark the end of the parameter section in a +game ID). + +Ideally, it should also not contain any other potentially controversial +punctuation; bear in mind when designing a string parameter format +that it will probably be used on both Windows and Unix command lines +under a variety of exciting shell quoting and metacharacter rules. +Sticking entirely to alphanumerics is the safest thing; if you really +need punctuation, you can probably get away with commas, periods or +underscores without causing anybody any major inconvenience. If you +venture far beyond that, you're likely to irritate _somebody_. + +(At the time of writing this, all existing games have purely +alphanumeric string parameter formats. Usually these involve a letter +denoting a parameter, followed optionally by a number giving the value +of that parameter, with a few mandatory parts at the beginning such as +numeric width and height separated by `x'.) + +If the `full' parameter is TRUE, this function should encode absolutely +everything in the `game_params', such that a subsequent call to +decode_params() (section 2.3.4) will yield an identical structure. +If `full' is FALSE, however, you should leave out anything which +is not necessary to describe a _specific puzzle instance_, i.e. +anything which only takes effect when a new puzzle is _generated_. +For example, the Solo `game_params' includes a difficulty rating used +when constructing new puzzles; but a Solo game ID need not explicitly +include the difficulty, since to describe a puzzle once generated it's +sufficient to give the grid dimensions and the location and contents +of the clue squares. (Indeed, one might very easily type in a puzzle +out of a newspaper without _knowing_ what its difficulty level is in +Solo's terminology.) Therefore. Solo's encode_params() only encodes the +difficulty level if `full' is set. + +2.3.4. decode_params() +---------------------- + + void (*decode_params)(game_params *params, char const *string); + +This function is the inverse of encode_params() (section 2.3.3). It +parses the supplied string and fills in the supplied `game_params' +structure. Note that the structure will _already_ have been allocated: +this function is not expected to create a _new_ `game_params', but to +modify an existing one. + +This function can receive a string which only encodes a subset of the +parameters. The most obvious way in which this can happen is if the +string was constructed by encode_params() with its `full' parameter set +to FALSE; however, it could also happen if the user typed in a parameter +set manually and missed something out. Be prepared to deal with a wide +range of possibilities. + +When dealing with a parameter which is not specified in the input +string, what to do requires a judgment call on the part of the +programmer. Sometimes it makes sense to adjust other parameters to bring +them into line with the new ones. In Mines, for example, you would +probably not want to keep the same mine count if the user dropped the +grid size and didn't specify one, since you might easily end up with +more mines than would actually fit in the grid! On the other hand, +sometimes it makes sense to leave the parameter alone: a Solo player +might reasonably expect to be able to configure size and difficulty +independently of one another. + +This function currently has no direct means of returning an error if the +string cannot be parsed at all. However, the returned `game_params' is +almost always subsequently passed to validate_params() (section 2.3.10), +so if you really want to signal parse errors, you could always have a +`char *' in your parameters structure which stored an error message, and +have validate_params() return it if it is non-NULL. + +2.3.5. free_params() +-------------------- + + void (*free_params)(game_params *params); + +This function frees a `game_params' structure, and any subsidiary +allocations contained within it. + +2.3.6. dup_params() +------------------- + + game_params *(*dup_params)(game_params *params); + +This function allocates a new `game_params' structure and initialises it +with an exact copy of the information in the one provided as input. It +returns a pointer to the new duplicate. + +2.3.7. `can_configure' +---------------------- + + int can_configure; + +This boolean data element is set to TRUE if the back end supports +custom parameter configuration via a dialog box. If it is TRUE, then +the functions configure() and custom_params() are expected to work. See +section 2.3.8 and section 2.3.9 for more details. + +2.3.8. configure() +------------------ + + config_item *(*configure)(game_params *params); + +This function is called when the user requests a dialog box for +custom parameter configuration. It returns a newly allocated array of +config_item structures, describing the GUI elements required in the +dialog box. The array should have one more element than the number of +controls, since it is terminated with a C_END marker (see below). Each +array element describes the control together with its initial value; the +front end will modify the value fields and return the updated array to +custom_params() (see section 2.3.9). + +The config_item structure contains the following elements: + + char *name; + int type; + char *sval; + int ival; + +`name' is an ASCII string giving the textual label for a GUI control. It +is _not_ expected to be dynamically allocated. + +`type' contains one of a small number of `enum' values defining what +type of control is being described. The meaning of the `sval' and `ival' +fields depends on the value in `type'. The valid values are: + +`C_STRING' + + Describes a text input box. (This is also used for numeric input. + The back end does not bother informing the front end that the box is + numeric rather than textual; some front ends do have the capacity + to take this into account, but I decided it wasn't worth the extra + complexity in the interface.) For this type, `ival' is unused, and + `sval' contains a dynamically allocated string representing the + contents of the input box. + +`C_BOOLEAN' + + Describes a simple checkbox. For this type, `sval' is unused, and + `ival' is TRUE or FALSE. + +`C_CHOICES' + + Describes a drop-down list presenting one of a small number of + fixed choices. For this type, `sval' contains a list of strings + describing the choices; the very first character of `sval' is + used as a delimiter when processing the rest (so that the strings + `:zero:one:two', `!zero!one!two' and `xzeroxonextwo' all define + a three-element list containing `zero', `one' and `two'). `ival' + contains the index of the currently selected element, numbering from + zero (so that in the above example, 0 would mean `zero' and 2 would + mean `two'). + + Note that for this control type, `sval' is _not_ dynamically + allocated, whereas it was for `C_STRING'. + +`C_END' + + Marks the end of the array of `config_item's. All other fields are + unused. + +The array returned from this function is expected to have filled in the +initial values of all the controls according to the input `game_params' +structure. + +If the game's `can_configure' flag is set to FALSE, this function is +never called and need not do anything at all. + +2.3.9. custom_params() +---------------------- + + game_params *(*custom_params)(config_item *cfg); + +This function is the counterpart to configure() (section 2.3.8). It +receives as input an array of `config_item's which was originally +created by configure(), but in which the control values have since been +changed in accordance with user input. Its function is to read the new +values out of the controls and return a newly allocated `game_params' +structure representing the user's chosen parameter set. + +(The front end will have modified the controls' _values_, but there will +still always be the same set of controls, in the same order, as provided +by configure(). It is not necessary to check the `name' and `type' +fields, although you could use assert() if you were feeling energetic.) + +This function is not expected to (and indeed _must not_) free the input +`config_item' array. (If the parameters fail to validate, the dialog box +will stay open.) + +If the game's `can_configure' flag is set to FALSE, this function is +never called and need not do anything at all. + +2.3.10. validate_params() +------------------------- + + char *(*validate_params)(game_params *params, int full); + +This function takes a `game_params' structure as input, and checks that +the parameters described in it fall within sensible limits. (At the very +least, grid dimensions should almost certainly be strictly positive, for +example.) + +Return value is NULL if no problems were found, or alternatively a (non- +dynamically-allocated) ASCII string describing the error in human- +readable form. + +If the `full' parameter is set, full validation should be performed: any +set of parameters which would not permit generation of a sensible puzzle +should be faulted. If `full' is _not_ set, the implication is that +these parameters are not going to be used for _generating_ a puzzle; so +parameters which can't even sensibly _describe_ a valid puzzle should +still be faulted, but parameters which only affect puzzle generation +should not be. + +(The `full' option makes a difference when parameter combinations are +non-orthogonal. For example, Net has a boolean option controlling +whether it enforces a unique solution; it turns out that it's impossible +to generate a uniquely soluble puzzle with wrapping walls and width +2, so validate_params() will complain if you ask for one. However, +if the user had just been playing a unique wrapping puzzle of a more +sensible width, and then pastes in a game ID acquired from somebody else +which happens to describe a _non_-unique wrapping width-2 puzzle, then +validate_params() will be passed a `game_params' containing the width +and wrapping settings from the new game ID and the uniqueness setting +from the old one. This would be faulted, if it weren't for the fact that +`full' is not set during this call, so Net ignores the inconsistency. +The resulting `game_params' is never subsequently used to generate a +puzzle; this is a promise made by the mid-end when it asks for a non- +full validation.) + +2.4. Handling game descriptions +------------------------------- + +In this section I present the functions that deal with a textual +description of a puzzle, i.e. the part that comes after the colon in a +descriptive-format game ID. + +2.4.1. new_desc() +----------------- + + char *(*new_desc)(game_params *params, random_state *rs, + char **aux, int interactive); + +This function is where all the really hard work gets done. This is +the function whose job is to randomly generate a new puzzle, ensuring +solubility and uniqueness as appropriate. + +As input it is given a `game_params' structure and a random state +(see section 5.1 for the random number API). It must invent a puzzle +instance, encode it in string form, and return a dynamically allocated C +string containing that encoding. + +Additionally, it may return a second dynamically allocated string +in `*aux'. (If it doesn't want to, then it can leave that parameter +completely alone; it isn't required to set it to NULL, although doing +so is harmless.) That string, if present, will be passed to solve() +(section 2.7.4) later on; so if the puzzle is generated in such a way +that a solution is known, then information about that solution can be +saved in `*aux' for solve() to use. + +The `interactive' parameter should be ignored by almost all puzzles. +Its purpose is to distinguish between generating a puzzle within a GUI +context for immediate play, and generating a puzzle in a command-line +context for saving to be played later. The only puzzle that currently +uses this distinction (and, I fervently hope, the only one which will +_ever_ need to use it) is Mines, which chooses a random first-click +location when generating puzzles non-interactively, but which waits +for the user to place the first click when interactive. If you think +you have come up with another puzzle which needs to make use of this +parameter, please think for at least ten minutes about whether there is +_any_ alternative! + +Note that game description strings are not required to contain an +encoding of parameters such as grid size; a game description is +never separated from the `game_params' it was generated with, so any +information contained in that structure need not be encoded again in the +game description. + +2.4.2. validate_desc() +---------------------- + + char *(*validate_desc)(game_params *params, char *desc); + +This function is given a game description, and its job is to validate +that it describes a puzzle which makes sense. + +To some extent it's up to the user exactly how far they take the phrase +`makes sense'; there are no particularly strict rules about how hard the +user is permitted to shoot themself in the foot when typing in a bogus +game description by hand. (For example, Rectangles will not verify that +the sum of all the numbers in the grid equals the grid's area. So a user +could enter a puzzle which was provably not soluble, and the program +wouldn't complain; there just wouldn't happen to be any sequence of +moves which solved it.) + +The one non-negotiable criterion is that any game description which +makes it through validate_desc() _must not_ subsequently cause a crash +or an assertion failure when fed to new_game() and thence to the rest of +the back end. + +The return value is NULL on success, or a non-dynamically-allocated C +string containing an error message. + +2.4.3. new_game() +----------------- + + game_state *(*new_game)(midend *me, game_params *params, + char *desc); + +This function takes a game description as input, together with its +accompanying `game_params', and constructs a `game_state' describing the +initial state of the puzzle. It returns a newly allocated `game_state' +structure. + +Almost all puzzles should ignore the `me' parameter. It is required by +Mines, which needs it for later passing to midend_supersede_game_desc() +(see section 2.11.2) once the user has placed the first click. I +fervently hope that no other puzzle will be awkward enough to require +it, so everybody else should ignore it. As with the `interactive' +parameter in new_desc() (section 2.4.1), if you think you have a reason +to need this parameter, please try very hard to think of an alternative +approach! + +2.5. Handling game states +------------------------- + +This section describes the functions which create and destroy +`game_state' structures. + +(Well, except new_game(), which is in section 2.4.3 instead of under +here; but it deals with game descriptions _and_ game states and it had +to go in one section or the other.) + +2.5.1. dup_game() +----------------- + + game_state *(*dup_game)(game_state *state); + +This function allocates a new `game_state' structure and initialises it +with an exact copy of the information in the one provided as input. It +returns a pointer to the new duplicate. + +2.5.2. free_game() +------------------ + + void (*free_game)(game_state *state); + +This function frees a `game_state' structure, and any subsidiary +allocations contained within it. + +2.6. Handling `game_ui' +----------------------- + +2.6.1. new_ui() +--------------- + + game_ui *(*new_ui)(game_state *state); + +This function allocates and returns a new `game_ui' structure for +playing a particular puzzle. It is passed a pointer to the initial +`game_state', in case it needs to refer to that when setting up the +initial values for the new game. + +2.6.2. free_ui() +---------------- + + void (*free_ui)(game_ui *ui); + +This function frees a `game_ui' structure, and any subsidiary +allocations contained within it. + +2.6.3. encode_ui() +------------------ + + char *(*encode_ui)(game_ui *ui); + +This function encodes any _important_ data in a `game_ui' structure in +string form. It is only called when saving a half-finished game to a +file. + +It should be used sparingly. Almost all data in a `game_ui' is not +important enough to save. The location of the keyboard-controlled +cursor, for example, can be reset to a default position on reloading +the game without impacting the user experience. If the user should +somehow manage to save a game while a mouse drag was in progress, then +discarding that mouse drag would be an outright _feature_, + +A typical thing that _would_ be worth encoding in this function is the +Mines death counter: it's in the `game_ui' rather than the `game_state' +because it's too important to allow the user to revert it by using Undo, +and therefore it's also too important to allow the user to revert it by +saving and reloading. (Of course, the user could edit the save file by +hand... But if the user is _that_ determined to cheat, they could just +as easily modify the game's source.) + +2.6.4. decode_ui() +------------------ + + void (*decode_ui)(game_ui *ui, char *encoding); + +This function parses a string previously output by encode_ui(), and +writes the decoded data back into the provided `game_ui' structure. + +2.6.5. changed_state() +---------------------- + + void (*changed_state)(game_ui *ui, game_state *oldstate, + game_state *newstate); + +This function is called by the mid-end whenever the current game state +changes, for any reason. Those reasons include: + + - a fresh move being made by interpret_move() and execute_move() + + - a solve operation being performed by solve() and execute_move() + + - the user moving back and forth along the undo list by means of the + Undo and Redo operations + + - the user selecting Restart to go back to the initial game state. + +The job of changed_state() is to update the `game_ui' for consistency +with the new game state, if any update is necessary. For example, +Same Game stores data about the currently selected tile group in its +`game_ui', and this data is intrinsically related to the game state it +was derived from. So it's very likely to become invalid when the game +state changes; thus, Same Game's changed_state() function clears the +current selection whenever it is called. + +When anim_length() or flash_length() are called, you can be sure that +there has been a previous call to changed_state(). So changed_state() +can set up data in the `game_ui' which will be read by anim_length() and +flash_length(), and those functions will not have to worry about being +called without the data having been initialised. + +2.7. Making moves +----------------- + +This section describes the functions which actually make moves in +the game: that is, the functions which process user input and end up +producing new `game_state's. + +2.7.1. interpret_move() +----------------------- + + char *(*interpret_move)(game_state *state, game_ui *ui, + game_drawstate *ds, + int x, int y, int button); + +This function receives user input and processes it. Its input parameters +are the current `game_state', the current `game_ui' and the current +`game_drawstate', plus details of the input event. `button' is either +an ASCII value or a special code (listed below) indicating an arrow or +function key or a mouse event; when `button' is a mouse event, `x' and +`y' contain the pixel coordinates of the mouse pointer relative to the +top left of the puzzle's drawing area. + +interpret_move() may return in three different ways: + + - Returning NULL indicates that no action whatsoever occurred in + response to the input event; the puzzle was not interested in it at + all. + + - Returning the empty string ("") indicates that the input event has + resulted in a change being made to the `game_ui' which will require + a redraw of the game window, but that no actual _move_ was made + (i.e. no new `game_state' needs to be created). + + - Returning anything else indicates that a move was made and that + a new `game_state' must be created. However, instead of actually + constructing a new `game_state' itself, this function is required to + return a string description of the details of the move. This string + will be passed to execute_move() (section 2.7.2) to actually create + the new `game_state'. (Encoding moves as strings in this way means + that the mid-end can keep the strings as well as the game states, + and the strings can be written to disk when saving the game and fed + to execute_move() again on reloading.) + +The return value from interpret_move() is expected to be dynamically +allocated if and only if it is not either NULL _or_ the empty string. + +After this function is called, the back end is permitted to rely on some +subsequent operations happening in sequence: + + - execute_move() will be called to convert this move description into + a new `game_state' + + - changed_state() will be called with the new `game_state'. + +This means that if interpret_move() needs to do updates to the `game_ui' +which are easier to perform by referring to the new `game_state', it can +safely leave them to be done in changed_state() and not worry about them +failing to happen. + +(Note, however, that execute_move() may _also_ be called in other +circumstances. It is only interpret_move() which can rely on a +subsequent call to changed_state().) + +The special key codes supported by this function are: + +LEFT_BUTTON, MIDDLE_BUTTON, RIGHT_BUTTON + + Indicate that one of the mouse buttons was pressed down. + +LEFT_DRAG, MIDDLE_DRAG, RIGHT_DRAG + + Indicate that the mouse was moved while one of the mouse buttons was + still down. The mid-end guarantees that when one of these events is + received, it will always have been preceded by a button-down event + (and possibly other drag events) for the same mouse button, and no + event involving another mouse button will have appeared in between. + +LEFT_RELEASE, MIDDLE_RELEASE, RIGHT_RELEASE + + Indicate that a mouse button was released. The mid-end guarantees + that when one of these events is received, it will always have been + preceded by a button-down event (and possibly some drag events) for + the same mouse button, and no event involving another mouse button + will have appeared in between. + +CURSOR_UP, CURSOR_DOWN, CURSOR_LEFT, CURSOR_RIGHT + + Indicate that an arrow key was pressed. + +CURSOR_SELECT + + On platforms which have a prominent `select' button alongside their + cursor keys, indicates that that button was pressed. + +In addition, there are some modifiers which can be bitwise-ORed into the +`button' parameter: + +MOD_CTRL, MOD_SHFT + + These indicate that the Control or Shift key was pressed alongside + the key. They only apply to the cursor keys, not to mouse buttons or + anything else. + +MOD_NUM_KEYPAD + + This applies to some ASCII values, and indicates that the key code + was input via the numeric keypad rather than the main keyboard. Some + puzzles may wish to treat this differently (for example, a puzzle + might want to use the numeric keypad as an eight-way directional + pad), whereas others might not (a game involving numeric input + probably just wants to treat the numeric keypad as numbers). + +MOD_MASK + + This mask is the bitwise OR of all the available modifiers; you can + bitwise-AND with ~MOD_MASK to strip all the modifiers off any input + value. + +2.7.2. execute_move() +--------------------- + + game_state *(*execute_move)(game_state *state, char *move); + +This function takes an input `game_state' and a move string as output +from interpret_move(). It returns a newly allocated `game_state' which +contains the result of applying the specified move to the input game +state. + +This function may return NULL if it cannot parse the move string (and +this is definitely preferable to crashing or failing an assertion, since +one way this can happen is if loading a corrupt save file). However, it +must not return NULL for any move string that really was output from +interpret_move(): this is punishable by assertion failure in the mid- +end. + +2.7.3. `can_solve' +------------------ + + int can_solve; + +This boolean field is set to TRUE if the game's solve() function does +something. If it's set to FALSE, the game will not even offer the +`Solve' menu option. + +2.7.4. solve() +-------------- + + char *(*solve)(game_state *orig, game_state *curr, + char *aux, char **error); + +This function is called when the user selects the `Solve' option from +the menu. + +It is passed two input game states: `orig' is the game state from the +very start of the puzzle, and `curr' is the current one. (Different +games find one or other or both of these convenient.) It is also passed +the `aux' string saved by new_desc() (section 2.4.1), in case that +encodes important information needed to provide the solution. + +If this function is unable to produce a solution (perhaps, for example, +the game has no in-built solver so it can only solve puzzles it invented +internally and has an `aux' string for) then it may return NULL. If it +does this, it must also set `*error' to an error message to be presented +to the user (such as `Solution not known for this puzzle'); that error +message is not expected to be dynamically allocated. + +If this function _does_ produce a solution, it returns a move string +suitable for feeding to execute_move() (section 2.7.2). + +2.8. Drawing the game graphics +------------------------------ + +This section discusses the back end functions that deal with drawing. + +2.8.1. new_drawstate() +---------------------- + + game_drawstate *(*new_drawstate)(drawing *dr, game_state *state); + +This function allocates and returns a new `game_drawstate' structure for +drawing a particular puzzle. It is passed a pointer to a `game_state', +in case it needs to refer to that when setting up any initial data. + +This function may not rely on the puzzle having been newly started; a +new draw state can be constructed at any time if the front end requests +a forced redraw. For games like Pattern, in which initial game states +are much simpler than general ones, this might be important to keep in +mind. + +The parameter `dr' is a drawing object (see chapter 3) which the +function might need to use to allocate blitters. (However, this isn't +recommended; it's usually more sensible to wait to allocate a blitter +until set_size() is called, because that way you can tailor it to the +scale at which the puzzle is being drawn.) + +2.8.2. free_drawstate() +----------------------- + + void (*free_drawstate)(drawing *dr, game_drawstate *ds); + +This function frees a `game_drawstate' structure, and any subsidiary +allocations contained within it. + +The parameter `dr' is a drawing object (see chapter 3), which might be +required if you are freeing a blitter. + +2.8.3. `preferred_tilesize' +--------------------------- + + int preferred_tilesize; + +Each game is required to define a single integer parameter which +expresses, in some sense, the scale at which it is drawn. This is +described in the APIs as `tilesize', since most puzzles are on a +square (or possibly triangular or hexagonal) grid and hence a sensible +interpretation of this parameter is to define it as the size of one grid +tile in pixels; however, there's no actual requirement that the `tile +size' be proportional to the game window size. Window size is required +to increase monotonically with `tile size', however. + +The data element `preferred_tilesize' indicates the tile size which +should be used in the absence of a good reason to do otherwise (such as +the screen being too small, or the user explicitly requesting a resize +if that ever gets implemented). + +2.8.4. compute_size() +--------------------- + + void (*compute_size)(game_params *params, int tilesize, + int *x, int *y); + +This function is passed a `game_params' structure and a tile size. It +returns, in `*x' and `*y', the size in pixels of the drawing area that +would be required to render a puzzle with those parameters at that tile +size. + +2.8.5. set_size() +----------------- + + void (*set_size)(drawing *dr, game_drawstate *ds, + game_params *params, int tilesize); + +This function is responsible for setting up a `game_drawstate' to draw +at a given tile size. Typically this will simply involve copying the +supplied `tilesize' parameter into a `tilesize' field inside the draw +state; for some more complex games it might also involve setting up +other dimension fields, or possibly allocating a blitter (see section +3.1.11). + +The parameter `dr' is a drawing object (see chapter 3), which is +required if a blitter needs to be allocated. + +Back ends may assume (and may enforce by assertion) that this function +will be called at most once for any `game_drawstate'. If a puzzle needs +to be redrawn at a different size, the mid-end will create a fresh +drawstate. + +2.8.6. colours() +---------------- + + float *(*colours)(frontend *fe, int *ncolours); + +This function is responsible for telling the front end what colours the +puzzle will need to draw itself. + +It returns the number of colours required in `*ncolours', and the return +value from the function itself is a dynamically allocated array of three +times that many `float's, containing the red, green and blue components +of each colour respectively as numbers in the range [0,1]. + +The second parameter passed to this function is a front end handle. +The only things it is permitted to do with this handle are to call the +front-end function called frontend_default_colour() (see section 4.30) +or the utility function called game_mkhighlight() (see section 5.4.7). +(The latter is a wrapper on the former, so front end implementors only +need to provide frontend_default_colour().) This allows colours() to +take local configuration into account when deciding on its own colour +allocations. Most games use the front end's default colour as their +background, apart from a few which depend on drawing relief highlights +so they adjust the background colour if it's too light for highlights to +show up against it. + +Note that the colours returned from this function are for _drawing_, +not for printing. Printing has an entirely different colour allocation +policy. + +2.8.7. anim_length() +-------------------- + + float (*anim_length)(game_state *oldstate, game_state *newstate, + int dir, game_ui *ui); + +This function is called when a move is made, undone or redone. It is +given the old and the new `game_state', and its job is to decide whether +the transition between the two needs to be animated or can be instant. + +`oldstate' is the state that was current until this call; `newstate' +is the state that will be current after it. `dir' specifies the +chronological order of those states: if it is positive, then the +transition is the result of a move or a redo (and so `newstate' is the +later of the two moves), whereas if it is negative then the transition +is the result of an undo (so that `newstate' is the _earlier_ move). + +If this function decides the transition should be animated, it returns +the desired length of the animation in seconds. If not, it returns zero. + +State changes as a result of a Restart operation are never animated; the +mid-end will handle them internally and never consult this function at +all. State changes as a result of Solve operations are also not animated +by default, although you can change this for a particular game by +setting a flag in `flags' (section 2.10.6). + +The function is also passed a pointer to the local `game_ui'. It may +refer to information in here to help with its decision (see section +6.3.7 for an example of this), and/or it may _write_ information about +the nature of the animation which will be read later by redraw(). + +When this function is called, it may rely on changed_state() having been +called previously, so if anim_length() needs to refer to information in +the `game_ui', then changed_state() is a reliable place to have set that +information up. + +Move animations do not inhibit further input events. If the user +continues playing before a move animation is complete, the animation +will be abandoned and the display will jump straight to the final state. + +2.8.8. flash_length() +--------------------- + + float (*flash_length)(game_state *oldstate, game_state *newstate, + int dir, game_ui *ui); + +This function is called when a move is completed. (`Completed' +means that not only has the move been made, but any animation which +accompanied it has finished.) It decides whether the transition from +`oldstate' to `newstate' merits a `flash'. + +A flash is much like a move animation, but it is _not_ interrupted by +further user interface activity; it runs to completion in parallel with +whatever else might be going on on the display. The only thing which +will rush a flash to completion is another flash. + +The purpose of flashes is to indicate that the game has been completed. +They were introduced as a separate concept from move animations because +of Net: the habit of most Net players (and certainly me) is to rotate a +tile into place and immediately lock it, then move on to another tile. +When you make your last move, at the instant the final tile is rotated +into place the screen starts to flash to indicate victory - but if you +then press the lock button out of habit, then the move animation is +cancelled, and the victory flash does not complete. (And if you _don't_ +press the lock button, the completed grid will look untidy because there +will be one unlocked square.) Therefore, I introduced a specific concept +of a `flash' which is separate from a move animation and can proceed in +parallel with move animations and any other display activity, so that +the victory flash in Net is not cancelled by that final locking move. + +The input parameters to flash_length() are exactly the same as the ones +to anim_length(). + +Just like anim_length(), when this function is called, it may rely on +changed_state() having been called previously, so if it needs to refer +to information in the `game_ui' then changed_state() is a reliable place +to have set that information up. + +(Some games use flashes to indicate defeat as well as victory; Mines, +for example, flashes in a different colour when you tread on a mine from +the colour it uses when you complete the game. In order to achieve this, +its flash_length() function has to store a flag in the `game_ui' to +indicate which flash type is required.) + +2.8.9. redraw() +--------------- + + void (*redraw)(drawing *dr, game_drawstate *ds, + game_state *oldstate, game_state *newstate, int dir, + game_ui *ui, float anim_time, float flash_time); + +This function is responsible for actually drawing the contents of +the game window, and for redrawing every time the game state or the +`game_ui' changes. + +The parameter `dr' is a drawing object which may be passed to the +drawing API functions (see chapter 3 for documentation of the drawing +API). This function may not save `dr' and use it elsewhere; it must only +use it for calling back to the drawing API functions within its own +lifetime. + +`ds' is the local `game_drawstate', of course, and `ui' is the local +`game_ui'. + +`newstate' is the semantically-current game state, and is always non- +NULL. If `oldstate' is also non-NULL, it means that a move has recently +been made and the game is still in the process of displaying an +animation linking the old and new states; in this situation, `anim_time' +will give the length of time (in seconds) that the animation has already +been running. If `oldstate' is NULL, then `anim_time' is unused (and +will hopefully be set to zero to avoid confusion). + +`flash_time', if it is is non-zero, denotes that the game is in the +middle of a flash, and gives the time since the start of the flash. See +section 2.8.8 for general discussion of flashes. + +The very first time this function is called for a new `game_drawstate', +it is expected to redraw the _entire_ drawing area. Since this often +involves drawing visual furniture which is never subsequently altered, +it is often simplest to arrange this by having a special `first time' +flag in the draw state, and resetting it after the first redraw. + +When this function (or any subfunction) calls the drawing API, it is +expected to pass colour indices which were previously defined by the +colours() function. + +2.9. Printing functions +----------------------- + +This section discusses the back end functions that deal with printing +puzzles out on paper. + +2.9.1. `can_print' +------------------ + + int can_print; + +This flag is set to TRUE if the puzzle is capable of printing itself +on paper. (This makes sense for some puzzles, such as Solo, which can +be filled in with a pencil. Other puzzles, such as Twiddle, inherently +involve moving things around and so would not make sense to print.) + +If this flag is FALSE, then the functions print_size() and print() will +never be called. + +2.9.2. `can_print_in_colour' +---------------------------- + + int can_print_in_colour; + +This flag is set to TRUE if the puzzle is capable of printing itself +differently when colour is available. For example, Map can actually +print coloured regions in different _colours_ rather than resorting to +cross-hatching. + +If the `can_print' flag is FALSE, then this flag will be ignored. + +2.9.3. print_size() +------------------- + + void (*print_size)(game_params *params, float *x, float *y); + +This function is passed a `game_params' structure and a tile size. It +returns, in `*x' and `*y', the preferred size in _millimetres_ of that +puzzle if it were to be printed out on paper. + +If the `can_print' flag is FALSE, this function will never be called. + +2.9.4. print() +-------------- + + void (*print)(drawing *dr, game_state *state, int tilesize); + +This function is called when a puzzle is to be printed out on paper. It +should use the drawing API functions (see chapter 3) to print itself. + +This function is separate from redraw() because it is often very +different: + + - The printing function may not depend on pixel accuracy, since + printer resolution is variable. Draw as if your canvas had infinite + resolution. + + - The printing function sometimes needs to display things in a + completely different style. Net, for example, is very different as + an on-screen puzzle and as a printed one. + + - The printing function is often much simpler since it has no need to + deal with repeated partial redraws. + +However, there's no reason the printing and redraw functions can't share +some code if they want to. + +When this function (or any subfunction) calls the drawing API, the +colour indices it passes should be colours which have been allocated by +the print_*_colour() functions within this execution of print(). This is +very different from the fixed small number of colours used in redraw(), +because printers do not have a limitation on the total number of colours +that may be used. Some puzzles' printing functions might wish to +allocate only one `ink' colour and use it for all drawing; others might +wish to allocate _more_ colours than are used on screen. + +One possible colour policy worth mentioning specifically is that a +puzzle's printing function might want to allocate the _same_ colour +indices as are used by the redraw function, so that code shared between +drawing and printing does not have to keep switching its colour indices. +In order to do this, the simplest thing is to make use of the fact that +colour indices returned from print_*_colour() are guaranteed to be in +increasing order from zero. So if you have declared an `enum' defining +three colours COL_BACKGROUND, COL_THIS and COL_THAT, you might then +write + + int c; + c = print_mono_colour(dr, 1); assert(c == COL_BACKGROUND); + c = print_mono_colour(dr, 0); assert(c == COL_THIS); + c = print_mono_colour(dr, 0); assert(c == COL_THAT); + +If the `can_print' flag is FALSE, this function will never be called. + +2.10. Miscellaneous +------------------- + +2.10.1. `can_format_as_text' +---------------------------- + + int can_format_as_text; + +This boolean field is TRUE if the game supports formatting a game state +as ASCII text (typically ASCII art) for copying to the clipboard and +pasting into other applications. If it is FALSE, front ends will not +offer the `Copy' command at all. + +If this field is FALSE, the function text_format() (section 2.10.2) is +not expected to do anything at all. + +2.10.2. text_format() +--------------------- + + char *(*text_format)(game_state *state); + +This function is passed a `game_state', and returns a newly allocated C +string containing an ASCII representation of that game state. It is used +to implement the `Copy' operation in many front ends. + +This function should only be called if the back end field +`can_format_as_text' (section 2.10.1) is TRUE. + +The returned string may contain line endings (and will probably want +to), using the normal C internal `\n' convention. For consistency +between puzzles, all multi-line textual puzzle representations should +_end_ with a newline as well as containing them internally. (There are +currently no puzzles which have a one-line ASCII representation, so +there's no precedent yet for whether that should come with a newline or +not.) + +2.10.3. wants_statusbar() +------------------------- + + int wants_statusbar; + +This boolean field is set to TRUE if the puzzle has a use for a textual +status line (to display score, completion status, currently active +tiles, etc). + +2.10.4. `is_timed' +------------------ + + int is_timed; + +This boolean field is TRUE if the puzzle is time-critical. If so, the +mid-end will maintain a game timer while the user plays. + +If this field is FALSE, then timing_state() will never be called and +need not do anything. + +2.10.5. timing_state() +---------------------- + + int (*timing_state)(game_state *state, game_ui *ui); + +This function is passed the current `game_state' and the local +`game_ui'; it returns TRUE if the game timer should currently be +running. + +A typical use for the `game_ui' in this function is to note when the +game was first completed (by setting a flag in changed_state() - see +section 2.6.5), and freeze the timer thereafter so that the user can +undo back through their solution process without altering their time. + +2.10.6. `flags' +--------------- + + int flags; + +This field contains miscellaneous per-backend flags. It consists of the +bitwise OR of some combination of the following: + +BUTTON_BEATS(x,y) + + Given any x and y from the set (LEFT_BUTTON, MIDDLE_BUTTON, + RIGHT_BUTTON), this macro evaluates to a bit flag which indicates + that when buttons x and y are both pressed simultaneously, the mid- + end should consider x to have priority. (In the absence of any such + flags, the mid-end will always consider the most recently pressed + button to have priority.) + +SOLVE_ANIMATES + + This flag indicates that moves generated by solve() (section 2.7.4) + are candidates for animation just like any other move. For most + games, solve moves should not be animated, so the mid-end doesn't + even bother calling anim_length() (section 2.8.7), thus saving some + special-case code in each game. On the rare occasion that animated + solve moves are actually required, you can set this flag. + +2.11. Things a back end may do on its own initiative +---------------------------------------------------- + +This section describes a couple of things that a back end may choose +to do by calling functions elsewhere in the program, which would not +otherwise be obvious. + +2.11.1. Create a random state +----------------------------- + +If a back end needs random numbers at some point during normal play, it +can create a fresh `random_state' by first calling `get_random_seed' +(section 4.26) and then passing the returned seed data to random_new(). + +This is likely not to be what you want. If a puzzle needs randomness in +the middle of play, it's likely to be more sensible to store some sort +of random state within the _game_state_, so that the random numbers are +tied to the particular game state and hence the player can't simply keep +undoing their move until they get numbers they like better. + +This facility is currently used only in Net, to implement the `jumble' +command, which sets every unlocked tile to a new random orientation. +This randomness _is_ a reasonable use of the feature, because it's non- +adversarial - there's no advantage to the user in getting different +random numbers. + +2.11.2. Supersede its own game description +------------------------------------------ + +In response to a move, a back end is (reluctantly) permitted to call +midend_supersede_game_desc(): + + void midend_supersede_game_desc(midend *me, + char *desc, char *privdesc); + +When the user selects `New Game', the mid-end calls new_desc() +(section 2.4.1) to get a new game description, and (as well as using +that to generate an initial game state) stores it for the save file +and for telling to the user. The function above overwrites that +game description, and also splits it in two. `desc' becomes the new +game description which is provided to the user on request, and is +also the one used to construct a new initial game state if the user +selects `Restart'. `privdesc' is a `private' game description, used to +reconstruct the game's initial state when reloading. + +The distinction between the two, as well as the need for this function +at all, comes from Mines. Mines begins with a blank grid and no +idea of where the mines actually are; new_desc() does almost no +work in interactive mode, and simply returns a string encoding the +`random_state'. When the user first clicks to open a tile, _then_ Mines +generates the mine positions, in such a way that the game is soluble +from that starting point. Then it uses this function to supersede the +random-state game description with a proper one. But it needs two: one +containing the initial click location (because that's what you want to +happen if you restart the game, and also what you want to send to a +friend so that they play _the same game_ as you), and one without the +initial click location (because when you save and reload the game, you +expect to see the same blank initial state as you had before saving). + +I should stress again that this function is a horrid hack. Nobody should +use it if they're not Mines; if you think you need to use it, think +again repeatedly in the hope of finding a better way to do whatever it +was you needed to do. + +3. The drawing API +------------------ + +The back end function redraw() (section 2.8.9) is required to draw the +puzzle's graphics on the window's drawing area, or on paper if the +puzzle is printable. To do this portably, it is provided with a drawing +API allowing it to talk directly to the front end. In this chapter I +document that API, both for the benefit of back end authors trying to +use it and for front end authors trying to implement it. + +The drawing API as seen by the back end is a collection of global +functions, each of which takes a pointer to a `drawing' structure (a +`drawing object'). These objects are supplied as parameters to the back +end's redraw() and print() functions. + +In fact these global functions are not implemented directly by the front +end; instead, they are implemented centrally in `drawing.c' and form a +small piece of middleware. The drawing API as supplied by the front end +is a structure containing a set of function pointers, plus a `void *' +handle which is passed to each of those functions. This enables a single +front end to switch between multiple implementations of the drawing API +if necessary. For example, the Windows API supplies a printing mechanism +integrated into the same GDI which deals with drawing in windows, and +therefore the same API implementation can handle both drawing and +printing; but on Unix, the most common way for applications to print +is by producing PostScript output directly, and although it would be +_possible_ to write a single (say) draw_rect() function which checked +a global flag to decide whether to do GTK drawing operations or output +PostScript to a file, it's much nicer to have two separate functions and +switch between them as appropriate. + +When drawing, the puzzle window is indexed by pixel coordinates, with +the top left pixel defined as (0,0) and the bottom right pixel (w-1,h- +1), where `w' and `h' are the width and height values returned by the +back end function compute_size() (section 2.8.4). + +When printing, the puzzle's print area is indexed in exactly the same +way (with an arbitrary tile size provided by the printing module +`printing.c'), to facilitate sharing of code between the drawing and +printing routines. However, when printing, puzzles may no longer assume +that the coordinate unit has any relationship to a pixel; the printer's +actual resolution might very well not even be known at print time, so +the coordinate unit might be smaller or larger than a pixel. Puzzles' +print functions should restrict themselves to drawing geometric shapes +rather than fiddly pixel manipulation. + +_Puzzles' redraw functions may assume that the surface they draw on is +persistent_. It is the responsibility of every front end to preserve the +puzzle's window contents in the face of GUI window expose issues and +similar. It is not permissible to request the back end redraw any part +of a window that it has already drawn, unless something has actually +changed as a result of making moves in the puzzle. + +Most front ends accomplish this by having the drawing routines draw on a +stored bitmap rather than directly on the window, and copying the bitmap +to the window every time a part of the window needs to be redrawn. +Therefore, it is vitally important that whenever the back end does any +drawing it informs the front end of which parts of the window it has +accessed, and hence which parts need repainting. This is done by calling +draw_update() (section 3.1.9). + +In the following sections I first discuss the drawing API as seen by the +back end, and then the _almost_ identical function-pointer form seen by +the front end. + +3.1. Drawing API as seen by the back end +---------------------------------------- + +This section documents the back-end drawing API, in the form of +functions which take a `drawing' object as an argument. + +3.1.1. draw_rect() +------------------ + + void draw_rect(drawing *dr, int x, int y, int w, int h, + int colour); + +Draws a filled rectangle in the puzzle window. + +`x' and `y' give the coordinates of the top left pixel of the rectangle. +`w' and `h' give its width and height. Thus, the horizontal extent of +the rectangle runs from `x' to `x+w-1' inclusive, and the vertical +extent from `y' to `y+h-1' inclusive. + +`colour' is an integer index into the colours array returned by the back +end function colours() (section 2.8.6). + +There is no separate pixel-plotting function. If you want to plot a +single pixel, the approved method is to use draw_rect() with width and +height set to 1. + +Unlike many of the other drawing functions, this function is guaranteed +to be pixel-perfect: the rectangle will be sharply defined and not anti- +aliased or anything like that. + +This function may be used for both drawing and printing. + +3.1.2. draw_rect_outline() +-------------------------- + + void draw_rect_outline(drawing *dr, int x, int y, int w, int h, + int colour); + +Draws an outline rectangle in the puzzle window. + +`x' and `y' give the coordinates of the top left pixel of the rectangle. +`w' and `h' give its width and height. Thus, the horizontal extent of +the rectangle runs from `x' to `x+w-1' inclusive, and the vertical +extent from `y' to `y+h-1' inclusive. + +`colour' is an integer index into the colours array returned by the back +end function colours() (section 2.8.6). + +From a back end perspective, this function may be considered to be part +of the drawing API. However, front ends are not required to implement +it, since it is actually implemented centrally (in misc.c) as a wrapper +on draw_polygon(). + +This function may be used for both drawing and printing. + +3.1.3. draw_line() +------------------ + + void draw_line(drawing *dr, int x1, int y1, int x2, int y2, + int colour); + +Draws a straight line in the puzzle window. + +`x1' and `y1' give the coordinates of one end of the line. `x2' and `y2' +give the coordinates of the other end. The line drawn includes both +those points. + +`colour' is an integer index into the colours array returned by the back +end function colours() (section 2.8.6). + +Some platforms may perform anti-aliasing on this function. Therefore, do +not assume that you can erase a line by drawing the same line over it +in the background colour; anti-aliasing might lead to perceptible ghost +artefacts around the vanished line. + +This function may be used for both drawing and printing. + +3.1.4. draw_polygon() +--------------------- + + void draw_polygon(drawing *dr, int *coords, int npoints, + int fillcolour, int outlinecolour); + +Draws an outlined or filled polygon in the puzzle window. + +`coords' is an array of (2*npoints) integers, containing the `x' and `y' +coordinates of `npoints' vertices. + +`fillcolour' and `outlinecolour' are integer indices into the colours +array returned by the back end function colours() (section 2.8.6). +`fillcolour' may also be -1 to indicate that the polygon should be +outlined only. + +The polygon defined by the specified list of vertices is first filled in +`fillcolour', if specified, and then outlined in `outlinecolour'. + +`outlinecolour' may _not_ be -1; it must be a valid colour (and front +ends are permitted to enforce this by assertion). This is because +different platforms disagree on whether a filled polygon should include +its boundary line or not, so drawing _only_ a filled polygon would +have non-portable effects. If you want your filled polygon not to +have a visible outline, you must set `outlinecolour' to the same as +`fillcolour'. + +Some platforms may perform anti-aliasing on this function. Therefore, do +not assume that you can erase a polygon by drawing the same polygon over +it in the background colour. Also, be prepared for the polygon to extend +a pixel beyond its obvious bounding box as a result of this; if you +really need it not to do this to avoid interfering with other delicate +graphics, you should probably use clip() (section 3.1.7). + +This function may be used for both drawing and printing. + +3.1.5. draw_circle() +-------------------- + + void draw_circle(drawing *dr, int cx, int cy, int radius, + int fillcolour, int outlinecolour); + +Draws an outlined or filled circle in the puzzle window. + +`cx' and `cy' give the coordinates of the centre of the circle. `radius' +gives its radius. The total horizontal pixel extent of the circle is +from `cx-radius+1' to `cx+radius-1' inclusive, and the vertical extent +similarly around `cy'. + +`fillcolour' and `outlinecolour' are integer indices into the colours +array returned by the back end function colours() (section 2.8.6). +`fillcolour' may also be -1 to indicate that the circle should be +outlined only. + +The circle is first filled in `fillcolour', if specified, and then +outlined in `outlinecolour'. + +`outlinecolour' may _not_ be -1; it must be a valid colour (and front +ends are permitted to enforce this by assertion). This is because +different platforms disagree on whether a filled circle should include +its boundary line or not, so drawing _only_ a filled circle would +have non-portable effects. If you want your filled circle not to +have a visible outline, you must set `outlinecolour' to the same as +`fillcolour'. + +Some platforms may perform anti-aliasing on this function. Therefore, do +not assume that you can erase a circle by drawing the same circle over +it in the background colour. Also, be prepared for the circle to extend +a pixel beyond its obvious bounding box as a result of this; if you +really need it not to do this to avoid interfering with other delicate +graphics, you should probably use clip() (section 3.1.7). + +This function may be used for both drawing and printing. + +3.1.6. draw_text() +------------------ + + void draw_text(drawing *dr, int x, int y, int fonttype, + int fontsize, int align, int colour, char *text); + +Draws text in the puzzle window. + +`x' and `y' give the coordinates of a point. The relation of this point +to the location of the text is specified by `align', which is a bitwise +OR of horizontal and vertical alignment flags: + +ALIGN_VNORMAL + + Indicates that `y' is aligned with the baseline of the text. + +ALIGN_VCENTRE + + Indicates that `y' is aligned with the vertical centre of the + text. (In fact, it's aligned with the vertical centre of normal + _capitalised_ text: displaying two pieces of text with ALIGN_VCENTRE + at the same y-coordinate will cause their baselines to be aligned + with one another, even if one is an ascender and the other a + descender.) + +ALIGN_HLEFT + + Indicates that `x' is aligned with the left-hand end of the text. + +ALIGN_HCENTRE + + Indicates that `x' is aligned with the horizontal centre of the + text. + +ALIGN_HRIGHT + + Indicates that `x' is aligned with the right-hand end of the text. + +`fonttype' is either FONT_FIXED or FONT_VARIABLE, for a monospaced +or proportional font respectively. (No more detail than that may be +specified; it would only lead to portability issues between different +platforms.) + +`fontsize' is the desired size, in pixels, of the text. This size +corresponds to the overall point size of the text, not to any internal +dimension such as the cap-height. + +`colour' is an integer index into the colours array returned by the back +end function colours() (section 2.8.6). + +This function may be used for both drawing and printing. + +3.1.7. clip() +------------- + + void clip(drawing *dr, int x, int y, int w, int h); + +Establishes a clipping rectangle in the puzzle window. + +`x' and `y' give the coordinates of the top left pixel of the clipping +rectangle. `w' and `h' give its width and height. Thus, the horizontal +extent of the rectangle runs from `x' to `x+w-1' inclusive, and the +vertical extent from `y' to `y+h-1' inclusive. (These are exactly the +same semantics as draw_rect().) + +After this call, no drawing operation will affect anything outside the +specified rectangle. The effect can be reversed by calling unclip() +(section 3.1.8). + +Back ends should not assume that a clipping rectangle will be +automatically cleared up by the front end if it's left lying around; +that might work on current front ends, but shouldn't be relied upon. +Always explicitly call unclip(). + +This function may be used for both drawing and printing. + +3.1.8. unclip() +--------------- + + void unclip(drawing *dr); + +Reverts the effect of a previous call to clip(). After this call, all +drawing operations will be able to affect the entire puzzle window +again. + +This function may be used for both drawing and printing. + +3.1.9. draw_update() +-------------------- + + void draw_update(drawing *dr, int x, int y, int w, int h); + +Informs the front end that a rectangular portion of the puzzle window +has been drawn on and needs to be updated. + +`x' and `y' give the coordinates of the top left pixel of the update +rectangle. `w' and `h' give its width and height. Thus, the horizontal +extent of the rectangle runs from `x' to `x+w-1' inclusive, and the +vertical extent from `y' to `y+h-1' inclusive. (These are exactly the +same semantics as draw_rect().) + +The back end redraw function _must_ call this function to report any +changes it has made to the window. Otherwise, those changes may not +become immediately visible, and may then appear at an unpredictable +subsequent time such as the next time the window is covered and re- +exposed. + +This function is only important when drawing. It may be called when +printing as well, but doing so is not compulsory, and has no effect. +(So if you have a shared piece of code between the drawing and printing +routines, that code may safely call draw_update().) + +3.1.10. status_bar() +-------------------- + + void status_bar(drawing *dr, char *text); + +Sets the text in the game's status bar to `text'. The text is copied +from the supplied buffer, so the caller is free to deallocate or modify +the buffer after use. + +(This function is not exactly a _drawing_ function, but it shares with +the drawing API the property that it may only be called from within the +back end redraw function, so this is as good a place as any to document +it.) + +The supplied text is filtered through the mid-end for optional rewriting +before being passed on to the front end; the mid-end will prepend the +current game time if the game is timed (and may in future perform other +rewriting if it seems like a good idea). + +This function is for drawing only; it must never be called during +printing. + +3.1.11. Blitter functions +------------------------- + +This section describes a group of related functions which save and +restore a section of the puzzle window. This is most commonly used to +implement user interfaces involving dragging a puzzle element around the +window: at the end of each call to redraw(), if an object is currently +being dragged, the back end saves the window contents under that +location and then draws the dragged object, and at the start of the next +redraw() the first thing it does is to restore the background. + +The front end defines an opaque type called a `blitter', which is +capable of storing a rectangular area of a specified size. + +Blitter functions are for drawing only; they must never be called during +printing. + +3.1.11.1. blitter_new() +----------------------- + + blitter *blitter_new(drawing *dr, int w, int h); + +Creates a new blitter object which stores a rectangle of size `w' by `h' +pixels. Returns a pointer to the blitter object. + +Blitter objects are best stored in the `game_drawstate'. A good time to +create them is in the set_size() function (section 2.8.5), since it is +at this point that you first know how big a rectangle they will need to +save. + +3.1.11.2. blitter_free() +------------------------ + + void blitter_free(drawing *dr, blitter *bl); + +Disposes of a blitter object. Best called in free_drawstate(). (However, +check that the blitter object is not NULL before attempting to free it; +it is possible that a draw state might be created and freed without ever +having set_size() called on it in between.) + +3.1.11.3. blitter_save() +------------------------ + + void blitter_save(drawing *dr, blitter *bl, int x, int y); + +This is a true drawing API function, in that it may only be called from +within the game redraw routine. It saves a rectangular portion of the +puzzle window into the specified blitter object. + +`x' and `y' give the coordinates of the top left corner of the saved +rectangle. The rectangle's width and height are the ones specified when +the blitter object was created. + +This function is required to cope and do the right thing if `x' and `y' +are out of range. (The right thing probably means saving whatever part +of the blitter rectangle overlaps with the visible area of the puzzle +window.) + +3.1.11.4. blitter_load() +------------------------ + + void blitter_load(drawing *dr, blitter *bl, int x, int y); + +This is a true drawing API function, in that it may only be called from +within the game redraw routine. It restores a rectangular portion of the +puzzle window from the specified blitter object. + +`x' and `y' give the coordinates of the top left corner of the rectangle +to be restored. The rectangle's width and height are the ones specified +when the blitter object was created. + +Alternatively, you can specify both `x' and `y' as the special value +BLITTER_FROMSAVED, in which case the rectangle will be restored to +exactly where it was saved from. (This is probably what you want to do +almost all the time, if you're using blitters to implement draggable +puzzle elements.) + +This function is required to cope and do the right thing if `x' and +`y' (or the equivalent ones saved in the blitter) are out of range. +(The right thing probably means restoring whatever part of the blitter +rectangle overlaps with the visible area of the puzzle window.) + +If this function is called on a blitter which had previously been saved +from a partially out-of-range rectangle, then the parts of the saved +bitmap which were not visible at save time are undefined. If the blitter +is restored to a different position so as to make those parts visible, +the effect on the drawing area is undefined. + +3.1.12. print_mono_colour() +--------------------------- + + int print_mono_colour(drawing *dr, int grey); + +This function allocates a colour index for a simple monochrome colour +during printing. + +`grey' must be 0 or 1. If `grey' is 0, the colour returned is black; if +`grey' is 1, the colour is white. + +3.1.13. print_grey_colour() +--------------------------- + + int print_grey_colour(drawing *dr, int hatch, float grey); + +This function allocates a colour index for a grey-scale colour during +printing. + +`grey' may be any number between 0 (black) and 1 (white); for example, +0.5 indicates a medium grey. + +If printing in black and white only, the `grey' value will not be used; +instead, regions shaded in this colour will be hatched with parallel +lines. The `hatch' parameter defines what type of hatching should be +used in place of this colour: + +HATCH_SOLID + + In black and white, this colour will be replaced by solid black. + +HATCH_CLEAR + + In black and white, this colour will be replaced by solid white. + +HATCH_SLASH + + This colour will be hatched by lines slanting to the right at 45 + degrees. + +HATCH_BACKSLASH + + This colour will be hatched by lines slanting to the left at 45 + degrees. + +HATCH_HORIZ + + This colour will be hatched by horizontal lines. + +HATCH_VERT + + This colour will be hatched by vertical lines. + +HATCH_PLUS + + This colour will be hatched by criss-crossing horizontal and + vertical lines. + +HATCH_X + + This colour will be hatched by criss-crossing diagonal lines. + +Colours defined to use hatching may not be used for drawing lines; +they may only be used for filling areas. That is, they may be used as +the `fillcolour' parameter to draw_circle() and draw_polygon(), and +as the colour parameter to draw_rect(), but may not be used as the +`outlinecolour' parameter to draw_circle() or draw_polygon(), or with +draw_line(). + +3.1.14. print_rgb_colour() +-------------------------- + + int print_rgb_colour(drawing *dr, int hatch, + float r, float g, float b); + +This function allocates a colour index for a fully specified RGB colour +during printing. + +`r', `g' and `b' may each be anywhere in the range from 0 to 1. + +If printing in black and white only, these values will not be used; +instead, regions shaded in this colour will be hatched with parallel +lines. The `hatch' parameter defines what type of hatching should be +used in place of this colour; see section 3.1.13 for its definition. + +3.1.15. print_line_width() +-------------------------- + + void print_line_width(drawing *dr, int width); + +This function is called to set the thickness of lines drawn during +printing. It is meaningless in drawing: all lines drawn by draw_line(), +draw_circle and draw_polygon() are one pixel in thickness. However, in +printing there is no clear definition of a pixel and so line widths must +be explicitly specified. + +The line width is specified in the usual coordinate system. Note, +however, that it is a hint only: the central printing system may choose +to vary line thicknesses at user request or due to printer capabilities. + +3.2. The drawing API as implemented by the front end +---------------------------------------------------- + +This section describes the drawing API in the function-pointer form in +which it is implemented by a front end. + +(It isn't only platform-specific front ends which implement this API; +the platform-independent module `ps.c' also provides an implementation +of it which outputs PostScript. Thus, any platform which wants to do PS +printing can do so with minimum fuss.) + +The following entries all describe function pointer fields in a +structure called `drawing_api'. Each of the functions takes a `void *' +context pointer, which it should internally cast back to a more useful +type. Thus, a drawing _object_ (`drawing *)' suitable for passing to +the back end redraw or printing functions is constructed by passing a +`drawing_api' and a `void *' to the function drawing_new() (see section +3.3.1). + +3.2.1. draw_text() +------------------ + + void (*draw_text)(void *handle, int x, int y, int fonttype, + int fontsize, int align, int colour, char *text); + +This function behaves exactly like the back end draw_text() function; +see section 3.1.6. + +3.2.2. draw_rect() +------------------ + + void (*draw_rect)(void *handle, int x, int y, int w, int h, + int colour); + +This function behaves exactly like the back end draw_rect() function; +see section 3.1.1. + +3.2.3. draw_line() +------------------ + + void (*draw_line)(void *handle, int x1, int y1, int x2, int y2, + int colour); + +This function behaves exactly like the back end draw_line() function; +see section 3.1.3. + +3.2.4. draw_polygon() +--------------------- + + void (*draw_polygon)(void *handle, int *coords, int npoints, + int fillcolour, int outlinecolour); + +This function behaves exactly like the back end draw_polygon() function; +see section 3.1.4. + +3.2.5. draw_circle() +-------------------- + + void (*draw_circle)(void *handle, int cx, int cy, int radius, + int fillcolour, int outlinecolour); + +This function behaves exactly like the back end draw_circle() function; +see section 3.1.5. + +3.2.6. draw_update() +-------------------- + + void (*draw_update)(void *handle, int x, int y, int w, int h); + +This function behaves exactly like the back end draw_text() function; +see section 3.1.6. + +An implementation of this API which only supports printing is permitted +to define this function pointer to be NULL rather than bothering to +define an empty function. The middleware in drawing.c will notice and +avoid calling it. + +3.2.7. clip() +------------- + + void (*clip)(void *handle, int x, int y, int w, int h); + +This function behaves exactly like the back end clip() function; see +section 3.1.7. + +3.2.8. unclip() +--------------- + + void (*unclip)(void *handle); + +This function behaves exactly like the back end unclip() function; see +section 3.1.8. + +3.2.9. start_draw() +------------------- + + void (*start_draw)(void *handle); + +This function is called at the start of drawing. It allows the front end +to initialise any temporary data required to draw with, such as device +contexts. + +Implementations of this API which do not provide drawing services may +define this function pointer to be NULL; it will never be called unless +drawing is attempted. + +3.2.10. end_draw() +------------------ + + void (*end_draw)(void *handle); + +This function is called at the end of drawing. It allows the front end +to do cleanup tasks such as deallocating device contexts and scheduling +appropriate GUI redraw events. + +Implementations of this API which do not provide drawing services may +define this function pointer to be NULL; it will never be called unless +drawing is attempted. + +3.2.11. status_bar() +-------------------- + + void (*status_bar)(void *handle, char *text); + +This function behaves exactly like the back end status_bar() function; +see section 3.1.10. + +Front ends implementing this function need not worry about it +being called repeatedly with the same text; the middleware code in +status_bar() will take care of this. + +Implementations of this API which do not provide drawing services may +define this function pointer to be NULL; it will never be called unless +drawing is attempted. + +3.2.12. blitter_new() +--------------------- + + blitter *(*blitter_new)(void *handle, int w, int h); + +This function behaves exactly like the back end blitter_new() function; +see section 3.1.11.1. + +Implementations of this API which do not provide drawing services may +define this function pointer to be NULL; it will never be called unless +drawing is attempted. + +3.2.13. blitter_free() +---------------------- + + void (*blitter_free)(void *handle, blitter *bl); + +This function behaves exactly like the back end blitter_free() function; +see section 3.1.11.2. + +Implementations of this API which do not provide drawing services may +define this function pointer to be NULL; it will never be called unless +drawing is attempted. + +3.2.14. blitter_save() +---------------------- + + void (*blitter_save)(void *handle, blitter *bl, int x, int y); + +This function behaves exactly like the back end blitter_save() function; +see section 3.1.11.3. + +Implementations of this API which do not provide drawing services may +define this function pointer to be NULL; it will never be called unless +drawing is attempted. + +3.2.15. blitter_load() +---------------------- + + void (*blitter_load)(void *handle, blitter *bl, int x, int y); + +This function behaves exactly like the back end blitter_load() function; +see section 3.1.11.4. + +Implementations of this API which do not provide drawing services may +define this function pointer to be NULL; it will never be called unless +drawing is attempted. + +3.2.16. begin_doc() +------------------- + + void (*begin_doc)(void *handle, int pages); + +This function is called at the beginning of a printing run. It gives the +front end an opportunity to initialise any required printing subsystem. +It also provides the number of pages in advance. + +Implementations of this API which do not provide printing services may +define this function pointer to be NULL; it will never be called unless +printing is attempted. + +3.2.17. begin_page() +-------------------- + + void (*begin_page)(void *handle, int number); + +This function is called during printing, at the beginning of each page. +It gives the page number (numbered from 1 rather than 0, so suitable for +use in user-visible contexts). + +Implementations of this API which do not provide printing services may +define this function pointer to be NULL; it will never be called unless +printing is attempted. + +3.2.18. begin_puzzle() +---------------------- + + void (*begin_puzzle)(void *handle, float xm, float xc, + float ym, float yc, int pw, int ph, float wmm); + +This function is called during printing, just before printing a single +puzzle on a page. It specifies the size and location of the puzzle on +the page. + +`xm' and `xc' specify the horizontal position of the puzzle on the page, +as a linear function of the page width. The front end is expected to +multiply the page width by `xm', add `xc' (measured in millimetres), and +use the resulting x-coordinate as the left edge of the puzzle. + +Similarly, `ym' and `yc' specify the vertical position of the puzzle as +a function of the page height: the page height times `xm', plus `xc' +millimetres, equals the desired distance from the top of the page to the +top of the puzzle. + +(This unwieldy mechanism is required because not all printing systems +can communicate the page size back to the software. The PostScript back +end, for example, writes out PS which determines the page size at print +time by means of calling `clippath', and centres the puzzles within +that. Thus, exactly the same PS file works on A4 or on US Letter paper +without needing local configuration, which simplifies matters.) + +pw and ph give the size of the puzzle in drawing API coordinates. The +printing system will subsequently call the puzzle's own print function, +which will in turn call drawing API functions in the expectation that an +area pw by ph units is available to draw the puzzle on. + +Finally, wmm gives the desired width of the puzzle in millimetres. (The +aspect ratio is expected to be preserved, so if the desired puzzle +height is also needed then it can be computed as wmm*ph/pw.) + +Implementations of this API which do not provide printing services may +define this function pointer to be NULL; it will never be called unless +printing is attempted. + +3.2.19. end_puzzle() +-------------------- + + void (*end_puzzle)(void *handle); + +This function is called after the printing of a specific puzzle is +complete. + +Implementations of this API which do not provide printing services may +define this function pointer to be NULL; it will never be called unless +printing is attempted. + +3.2.20. end_page() +------------------ + + void (*end_page)(void *handle, int number); + +This function is called after the printing of a page is finished. + +Implementations of this API which do not provide printing services may +define this function pointer to be NULL; it will never be called unless +printing is attempted. + +3.2.21. end_doc() +----------------- + + void (*end_doc)(void *handle); + +This function is called after the printing of the entire document is +finished. This is the moment to close files, send things to the print +spooler, or whatever the local convention is. + +Implementations of this API which do not provide printing services may +define this function pointer to be NULL; it will never be called unless +printing is attempted. + +3.2.22. line_width() +-------------------- + + void (*line_width)(void *handle, float width); + +This function is called to set the line thickness, during printing only. +Note that the width is a float here, where it was an int as seen by the +back end. This is because drawing.c may have scaled it on the way past. + +However, the width is still specified in the same coordinate system as +the rest of the drawing. + +Implementations of this API which do not provide printing services may +define this function pointer to be NULL; it will never be called unless +printing is attempted. + +3.3. The drawing API as called by the front end +----------------------------------------------- + +There are a small number of functions provided in drawing.c which the +front end needs to _call_, rather than helping to implement. They are +described in this section. + +3.3.1. drawing_new() +-------------------- + + drawing *drawing_new(const drawing_api *api, midend *me, + void *handle); + +This function creates a drawing object. It is passed a `drawing_api', +which is a structure containing nothing but function pointers; and also +a `void *' handle. The handle is passed back to each function pointer +when it is called. + +The `midend' parameter is used for rewriting the status bar contents: +status_bar() (see section 3.1.10) has to call a function in the mid- +end which might rewrite the status bar text. If the drawing object +is to be used only for printing, or if the game is known not to call +status_bar(), this parameter may be NULL. + +3.3.2. drawing_free() +--------------------- + + void drawing_free(drawing *dr); + +This function frees a drawing object. Note that the `void *' handle is +not freed; if that needs cleaning up it must be done by the front end. + +3.3.3. print_get_colour() +------------------------- + + void print_get_colour(drawing *dr, int colour, int *hatch, + float *r, float *g, float *b) + +This function is called by the implementations of the drawing API +functions when they are called in a printing context. It takes a colour +index as input, and returns the description of the colour as requested +by the back end. + +`*r', `*g' and `*b' are filled with the RGB values of the desired colour +if printing in colour. + +`*hatch' is filled with the type of hatching (or not) desired if +printing in black and white. See section 3.1.13 for details of the +values this integer can take. + +4. The API provided by the mid-end +---------------------------------- + +This chapter documents the API provided by the mid-end to be called by +the front end. You probably only need to read this if you are a front +end implementor, i.e. you are porting Puzzles to a new platform. If +you're only interested in writing new puzzles, you can safely skip this +chapter. + +All the persistent state in the mid-end is encapsulated within a +`midend' structure, to facilitate having multiple mid-ends in any +port which supports multiple puzzle windows open simultaneously. Each +`midend' is intended to handle the contents of a single puzzle window. + +4.1. midend_new() +----------------- + + midend *midend_new(frontend *fe, const game *ourgame, + const drawing_api *drapi, void *drhandle) + +Allocates and returns a new mid-end structure. + +The `fe' argument is stored in the mid-end. It will be used when calling +back to functions such as activate_timer() (section 4.27), and will be +passed on to the back end function colours() (section 2.8.6). + +The parameters `drapi' and `drhandle' are passed to drawing_new() +(section 3.3.1) to construct a drawing object which will be passed to +the back end function redraw() (section 2.8.9). Hence, all drawing- +related function pointers defined in `drapi' can expect to be called +with `drhandle' as their first argument. + +The `ourgame' argument points to a container structure describing a game +back end. The mid-end thus created will only be capable of handling that +one game. (So even in a monolithic front end containing all the games, +this imposes the constraint that any individual puzzle window is tied to +a single game. Unless, of course, you feel brave enough to change the +mid-end for the window without closing the window...) + +4.2. midend_free() +------------------ + + void midend_free(midend *me); + +Frees a mid-end structure and all its associated data. + +4.3. midend_set_params() +------------------------ + + void midend_set_params(midend *me, game_params *params); + +Sets the current game parameters for a mid-end. Subsequent games +generated by midend_new_game() (section 4.6) will use these parameters +until further notice. + +The usual way in which the front end will have an actual `game_params' +structure to pass to this function is if it had previously got it from +midend_fetch_preset() (section 4.14). Thus, this function is usually +called in response to the user making a selection from the presets menu. + +4.4. midend_get_params() +------------------------ + + game_params *midend_get_params(midend *me); + +Returns the current game parameters stored in this mid-end. + +The returned value is dynamically allocated, and should be freed when +finished with by passing it to the game's own free_params() function +(see section 2.3.5). + +4.5. midend_size() +------------------ + + void midend_size(midend *me, int *x, int *y, int expand); + +Tells the mid-end to figure out its window size. + +On input, `*x' and `*y' should contain the maximum or requested size +for the window. (Typically this will be the size of the screen that the +window has to fit on, or similar.) The mid-end will repeatedly call the +back end function compute_size() (section 2.8.4), searching for a tile +size that best satisfies the requirements. On exit, `*x' and `*y' will +contain the size needed for the puzzle window's drawing area. (It is +of course up to the front end to adjust this for any additional window +furniture such as menu bars and window borders, if necessary. The status +bar is also not included in this size.) + +If `expand' is set to FALSE, then the game's tile size will never go +over its preferred one. This is the recommended approach when opening a +new window at default size: the game will use its preferred size unless +it has to use a smaller one to fit on the screen. + +If `expand' is set to TRUE, the mid-end will pick a tile size which +approximates the input size _as closely as possible_, and will go over +the game's preferred tile size if necessary to achieve this. Use this +option if you want your front end to support dynamic resizing of the +puzzle window with automatic scaling of the puzzle to fit. + +The mid-end will try as hard as it can to return a size which is +less than or equal to the input size, in both dimensions. In extreme +circumstances it may fail (if even the lowest possible tile size gives +window dimensions greater than the input), in which case it will return +a size greater than the input size. Front ends should be prepared +for this to happen (i.e. don't crash or fail an assertion), but may +handle it in any way they see fit: by rejecting the game parameters +which caused the problem, by opening a window larger than the screen +regardless of inconvenience, by introducing scroll bars on the window, +by drawing on a large bitmap and scaling it into a smaller window, or by +any other means you can think of. It is likely that when the tile size +is that small the game will be unplayable anyway, so don't put _too_ +much effort into handling it creatively. + +If your platform has no limit on window size (or if you're planning to +use scroll bars for large puzzles), you can pass dimensions of INT_MAX +as input to this function. You should probably not do that _and_ set the +`expand' flag, though! + +4.6. midend_new_game() +---------------------- + + void midend_new_game(midend *me); + +Causes the mid-end to begin a new game. Normally the game will be a +new randomly generated puzzle. However, if you have previously called +midend_game_id() or midend_set_config(), the game generated might be +dictated by the results of those functions. (In particular, you _must_ +call midend_new_game() after calling either of those functions, or else +no immediate effect will be visible.) + +You will probably need to call midend_size() after calling this +function, because if the game parameters have been changed since the +last new game then the window size might need to change. (If you know +the parameters _haven't_ changed, you don't need to do this.) + +This function will create a new `game_drawstate', but does not actually +perform a redraw (since you often need to call midend_size() before +the redraw can be done). So after calling this function and after +calling midend_size(), you should then call midend_redraw(). (It is not +necessary to call midend_force_redraw(); that will discard the draw +state and create a fresh one, which is unnecessary in this case since +there's a fresh one already. It would work, but it's usually excessive.) + +4.7. midend_restart_game() +-------------------------- + + void midend_restart_game(midend *me); + +This function causes the current game to be restarted. This is done by +placing a new copy of the original game state on the end of the undo +list (so that an accidental restart can be undone). + +This function automatically causes a redraw, i.e. the front end can +expect its drawing API to be called from _within_ a call to this +function. + +4.8. midend_force_redraw() +-------------------------- + + void midend_force_redraw(midend *me); + +Forces a complete redraw of the puzzle window, by means of discarding +the current `game_drawstate' and creating a new one from scratch before +calling the game's redraw() function. + +The front end can expect its drawing API to be called from within a call +to this function. + +4.9. midend_redraw() +-------------------- + + void midend_redraw(midend *me); + +Causes a partial redraw of the puzzle window, by means of simply calling +the game's redraw() function. (That is, the only things redrawn will be +things that have changed since the last redraw.) + +The front end can expect its drawing API to be called from within a call +to this function. + +4.10. midend_process_key() +-------------------------- + + int midend_process_key(midend *me, int x, int y, int button); + +The front end calls this function to report a mouse or keyboard event. +The parameters `x', `y' and `button' are almost identical to the ones +passed to the back end function interpret_move() (section 2.7.1), except +that the front end is _not_ required to provide the guarantees about +mouse event ordering. The mid-end will sort out multiple simultaneous +button presses and changes of button; the front end's responsibility +is simply to pass on the mouse events it receives as accurately as +possible. + +(Some platforms may need to emulate absent mouse buttons by means of +using a modifier key such as Shift with another mouse button. This tends +to mean that if Shift is pressed or released in the middle of a mouse +drag, the mid-end will suddenly stop receiving, say, LEFT_DRAG events +and start receiving RIGHT_DRAGs, with no intervening button release or +press events. This too is something which the mid-end will sort out for +you; the front end has no obligation to maintain sanity in this area.) + +The front end _should_, however, always eventually send some kind of +button release. On some platforms this requires special effort: Windows, +for example, requires a call to the system API function SetCapture() in +order to ensure that your window receives a mouse-up event even if the +pointer has left the window by the time the mouse button is released. +On any platform that requires this sort of thing, the front end _is_ +responsible for doing it. + +Calling this function is very likely to result in calls back to the +front end's drawing API and/or activate_timer() (section 4.27). + +4.11. midend_colours() +---------------------- + + float *midend_colours(midend *me, int *ncolours); + +Returns an array of the colours required by the game, in exactly +the same format as that returned by the back end function colours() +(section 2.8.6). Front ends should call this function rather than +calling the back end's version directly, since the mid-end adds standard +customisation facilities. (At the time of writing, those customisation +facilities are implemented hackily by means of environment variables, +but it's not impossible that they may become more full and formal in +future.) + +4.12. midend_timer() +-------------------- + + void midend_timer(midend *me, float tplus); + +If the mid-end has called activate_timer() (section 4.27) to request +regular callbacks for purposes of animation or timing, this is the +function the front end should call on a regular basis. The argument +`tplus' gives the time, in seconds, since the last time either this +function was called or activate_timer() was invoked. + +One of the major purposes of timing in the mid-end is to perform move +animation. Therefore, calling this function is very likely to result in +calls back to the front end's drawing API. + +4.13. midend_num_presets() +-------------------------- + + int midend_num_presets(midend *me); + +Returns the number of game parameter presets supplied by this game. +Front ends should use this function and midend_fetch_preset() to +configure their presets menu rather than calling the back end directly, +since the mid-end adds standard customisation facilities. (At the time +of writing, those customisation facilities are implemented hackily by +means of environment variables, but it's not impossible that they may +become more full and formal in future.) + +4.14. midend_fetch_preset() +--------------------------- + + void midend_fetch_preset(midend *me, int n, + char **name, game_params **params); + +Returns one of the preset game parameter structures for the game. +On input `n' must be a non-negative integer and less than the value +returned from midend_num_presets(). On output, `*name' is set to an +ASCII string suitable for entering in the game's presets menu, and +`*params' is set to the corresponding `game_params' structure. + +Both of the two output values are dynamically allocated, but they are +owned by the mid-end structure: the front end should not ever free them +directly, because they will be freed automatically during midend_free(). + +4.15. midend_wants_statusbar() +------------------------------ + + int midend_wants_statusbar(midend *me); + +This function returns TRUE if the puzzle has a use for a textual status +line (to display score, completion status, currently active tiles, time, +or anything else). + +Front ends should call this function rather than talking directly to the +back end. + +4.16. midend_get_config() +------------------------- + + config_item *midend_get_config(midend *me, int which, + char **wintitle); + +Returns a dialog box description for user configuration. + +On input, which should be set to one of three values, which select which +of the various dialog box descriptions is returned: + +CFG_SETTINGS + + Requests the GUI parameter configuration box generated by the puzzle + itself. This should be used when the user selects `Custom' from the + game types menu (or equivalent). The mid-end passes this request on + to the back end function configure() (section 2.3.8). + +CFG_DESC + + Requests a box suitable for entering a descriptive game ID (and + viewing the existing one). The mid-end generates this dialog box + description itself. This should be used when the user selects + `Specific' from the game menu (or equivalent). + +CFG_SEED + + Requests a box suitable for entering a random-seed game ID (and + viewing the existing one). The mid-end generates this dialog box + description itself. This should be used when the user selects + `Random Seed' from the game menu (or equivalent). + +The returned value is an array of config_items, exactly as described +in section 2.3.8. Another returned value is an ASCII string giving a +suitable title for the configuration window, in `*wintitle'. + +Both returned values are dynamically allocated and will need to be +freed. The window title can be freed in the obvious way; the config_item +array is a slightly complex structure, so a utility function free_cfg() +is provided to free it for you. See section 5.2.6. + +(Of course, you will probably not want to free the config_item array +until the dialog box is dismissed, because before then you will probably +need to pass it to midend_set_config.) + +4.17. midend_set_config() +------------------------- + + char *midend_set_config(midend *me, int which, + config_item *cfg); + +Passes the mid-end the results of a configuration dialog box. `which' +should have the same value which it had when midend_get_config() was +called; `cfg' should be the array of `config_item's returned from +midend_get_config(), modified to contain the results of the user's +editing operations. + +This function returns NULL on success, or otherwise (if the +configuration data was in some way invalid) an ASCII string containing +an error message suitable for showing to the user. + +If the function succeeds, it is likely that the game parameters will +have been changed and it is certain that a new game will be requested. +The front end should therefore call midend_new_game(), and probably also +re-think the window size using midend_size() and eventually perform a +refresh using midend_redraw(). + +4.18. midend_game_id() +---------------------- + + char *midend_game_id(midend *me, char *id); + +Passes the mid-end a string game ID (of any of the valid forms `params', +`params:description' or `params#seed') which the mid-end will process +and use for the next generated game. + +This function returns NULL on success, or otherwise (if the +configuration data was in some way invalid) an ASCII string containing +an error message (not dynamically allocated) suitable for showing to the +user. In the event of an error, the mid-end's internal state will be +left exactly as it was before the call. + +If the function succeeds, it is likely that the game parameters will +have been changed and it is certain that a new game will be requested. +The front end should therefore call midend_new_game(), and probably +also re-think the window size using midend_size() and eventually case a +refresh using midend_redraw(). + +4.19. midend_get_game_id() +-------------------------- + + char *midend_get_game_id(midend *me) + +Returns a descriptive game ID (i.e. one in the form +`params:description') describing the game currently active in the mid- +end. The returned string is dynamically allocated. + +4.20. midend_text_format() +-------------------------- + + char *midend_text_format(midend *me); + +Formats the current game's current state as ASCII text suitable for +copying to the clipboard. The returned string is dynamically allocated. + +You should not call this function if the game's `can_format_as_text' +flag is FALSE. + +If the returned string contains multiple lines (which is likely), it +will use the normal C line ending convention (\n only). On platforms +which use a different line ending convention for data in the clipboard, +it is the front end's responsibility to perform the conversion. + +4.21. midend_solve() +-------------------- + + char *midend_solve(midend *me); + +Requests the mid-end to perform a Solve operation. + +On success, NULL is returned. On failure, an error message (not +dynamically allocated) is returned, suitable for showing to the user. + +The front end can expect its drawing API and/or activate_timer() to be +called from within a call to this function. + +4.22. midend_serialise() +------------------------ + + void midend_serialise(midend *me, + void (*write)(void *ctx, void *buf, int len), + void *wctx); + +Calling this function causes the mid-end to convert its entire internal +state into a long ASCII text string, and to pass that string (piece by +piece) to the supplied `write' function. + +Desktop implementations can use this function to save a game in any +state (including half-finished) to a disk file, by supplying a `write' +function which is a wrapper on fwrite() (or local equivalent). Other +implementations may find other uses for it, such as compressing the +large and sprawling mid-end state into a manageable amount of memory +when a palmtop application is suspended so that another one can run; in +this case write might want to write to a memory buffer rather than a +file. There may be other uses for it as well. + +This function will call back to the supplied `write' function a number +of times, with the first parameter (`ctx') equal to `wctx', and the +other two parameters pointing at a piece of the output string. + +4.23. midend_deserialise() +-------------------------- + + char *midend_deserialise(midend *me, + int (*read)(void *ctx, void *buf, int len), + void *rctx); + +This function is the counterpart to midend_serialise(). It calls the +supplied read function repeatedly to read a quantity of data, and +attempts to interpret that data as a serialised mid-end as output by +midend_serialise(). + +The read function is called with the first parameter (`ctx') equal +to `rctx', and should attempt to read `len' bytes of data into the +buffer pointed to by `buf'. It should return FALSE on failure or TRUE +on success. It should not report success unless it has filled the +entire buffer; on platforms which might be reading from a pipe or other +blocking data source, `read' is responsible for looping until the whole +buffer has been filled. + +If the de-serialisation operation is successful, the mid-end's internal +data structures will be replaced by the results of the load, and NULL +will be returned. Otherwise, the mid-end's state will be completely +unchanged and an error message (typically some variation on `save file +is corrupt') will be returned. As usual, the error message string is not +dynamically allocated. + +If this function succeeds, it is likely that the game parameters will +have been changed. The front end should therefore probably re-think the +window size using midend_size(), and probably cause a refresh using +midend_redraw(). + +Because each mid-end is tied to a specific game back end, this function +will fail if you attempt to read in a save file generated by a different +game from the one configured in this mid-end, even if your application +is a monolithic one containing all the puzzles. (It would be pretty easy +to write a function which would look at a save file and determine which +game it was for; any front end implementor who needs such a function can +probably be accommodated.) + +4.24. Direct reference to the back end structure by the front end +----------------------------------------------------------------- + +Although _most_ things the front end needs done should be done by +calling the mid-end, there are a few situations in which the front end +needs to refer directly to the game back end structure. + +The most obvious of these is + + - passing the game back end as a parameter to midend_new(). + +There are a few other back end features which are not wrapped by the +mid-end because there didn't seem much point in doing so: + + - fetching the `name' field to use in window titles and similar + + - reading the `can_configure', `can_solve' and `can_format_as_text' + fields to decide whether to add those items to the menu bar or + equivalent + + - reading the `winhelp_topic' field (Windows only) + + - the GTK front end provides a `--generate' command-line option which + directly calls the back end to do most of its work. This is not + really part of the main front end code, though, and I'm not sure it + counts. + +In order to find the game back end structure, the front end does one of +two things: + + - If the particular front end is compiling a separate binary per game, + then the back end structure is a global variable with the standard + name `thegame': + + extern const game thegame; + + - If the front end is compiled as a monolithic application containing + all the puzzles together (in which case the preprocessor symbol + COMBINED must be defined when compiling most of the code base), then + there will be two global variables defined: + + extern const game *gamelist[]; + extern const int gamecount; + + `gamelist' will be an array of `gamecount' game structures, declared + in the source module `list.c'. The application should search that + array for the game it wants, probably by reaching into each game + structure and looking at its `name' field. + +4.25. Mid-end to front-end calls +-------------------------------- + +This section describes the small number of functions which a front end +must provide to be called by the mid-end or other standard utility +modules. + +4.26. get_random_seed() +----------------------- + + void get_random_seed(void **randseed, int *randseedsize); + +This function is called by a new mid-end, and also occasionally by game +back ends. Its job is to return a piece of data suitable for using as a +seed for initialisation of a new `random_state'. + +On exit, `*randseed' should be set to point at a newly allocated piece +of memory containing some seed data, and `*randseedsize' should be set +to the length of that data. + +A simple and entirely adequate implementation is to return a piece of +data containing the current system time at the highest conveniently +available resolution. + +4.27. activate_timer() +---------------------- + + void activate_timer(frontend *fe); + +This is called by the mid-end to request that the front end begin +calling it back at regular intervals. + +The timeout interval is left up to the front end; the finer it is, the +smoother move animations will be, but the more CPU time will be used. +Current front ends use values around 20ms (i.e. 50Hz). + +After this function is called, the mid-end will expect to receive calls +to midend_timer() on a regular basis. + +4.28. deactivate_timer() +------------------------ + + void deactivate_timer(frontend *fe); + +This is called by the mid-end to request that the front end stop calling +midend_timer(). + +4.29. fatal() +------------- + + void fatal(char *fmt, ...); + +This is called by some utility functions if they encounter a genuinely +fatal error such as running out of memory. It is a variadic function +in the style of printf(), and is expected to show the formatted error +message to the user any way it can and then terminate the application. +It must not return. + +4.30. frontend_default_colour() +------------------------------- + + void frontend_default_colour(frontend *fe, float *output); + +This function expects to be passed a pointer to an array of three +floats. It returns the platform's local preferred background colour +in those three floats, as red, green and blue values (in that order) +ranging from 0.0 to 1.0. + +This function should only ever be called by the back end function +colours() (section 2.8.6). (Thus, it isn't a _midend_-to-frontend +function as such, but there didn't seem to be anywhere else particularly +good to put it. Sorry.) + +5. Utility APIs +--------------- + +This chapter documents a variety of utility APIs provided for the +general use of the rest of the Puzzles code. + +5.1. Random number generation +----------------------------- + +Platforms' local random number generators vary widely in quality and +seed size. Puzzles therefore supplies its own high-quality random number +generator, with the additional advantage of giving the same results if +fed the same seed data on different platforms. This allows game random +seeds to be exchanged between different ports of Puzzles and still +generate the same games. + +Unlike the ANSI C rand() function, the Puzzles random number generator +has an _explicit_ state object called a `random_state'. One of these +is managed by each mid-end, for example, and passed to the back end to +generate a game with. + +5.1.1. random_new() +------------------- + + random_state *random_new(char *seed, int len); + +Allocates, initialises and returns a new `random_state'. The input data +is used as the seed for the random number stream (i.e. using the same +seed at a later time will generate the same stream). + +The seed data can be any data at all; there is no requirement to use +printable ASCII, or NUL-terminated strings, or anything like that. + +5.1.2. random_copy() +-------------------- + + random_state *random_copy(random_state *tocopy); + +Allocates a new `random_state', copies the contents of another +`random_state' into it, and returns the new state. If exactly the +same sequence of functions is subseqently called on both the copy and +the original, the results will be identical. This may be useful for +speculatively performing some operation using a given random state, and +later replaying that operation precisely. + +5.1.3. random_free() +-------------------- + + void random_free(random_state *state); + +Frees a `random_state'. + +5.1.4. random_bits() +-------------------- + + unsigned long random_bits(random_state *state, int bits); + +Returns a random number from 0 to 2^bits-1 inclusive. `bits' should be +between 1 and 32 inclusive. + +5.1.5. random_upto() +-------------------- + + unsigned long random_upto(random_state *state, unsigned long limit); + +Returns a random number from 0 to limit-1 inclusive. + +5.1.6. random_state_encode() +---------------------------- + + char *random_state_encode(random_state *state); + +Encodes the entire contents of a `random_state' in printable ASCII. +Returns a dynamically allocated string containing that encoding. This +can subsequently be passed to random_state_decode() to reconstruct the +same `random_state'. + +5.1.7. random_state_decode() +---------------------------- + + random_state *random_state_decode(char *input); + +Decodes a string generated by random_state_encode() and reconstructs an +equivalent `random_state' to the one encoded, i.e. it should produce the +same stream of random numbers. + +This function has no error reporting; if you pass it an invalid string +it will simply generate an arbitrary random state, which may turn out to +be noticeably non-random. + +5.1.8. shuffle() +---------------- + + void shuffle(void *array, int nelts, int eltsize, random_state *rs); + +Shuffles an array into a random order. The interface is much like ANSI C +qsort(), except that there's no need for a compare function. + +`array' is a pointer to the first element of the array. `nelts' is the +number of elements in the array; `eltsize' is the size of a single +element (typically measured using `sizeof'). `rs' is a `random_state' +used to generate all the random numbers for the shuffling process. + +5.2. Memory allocation +---------------------- + +Puzzles has some central wrappers on the standard memory allocation +functions, which provide compile-time type checking, and run-time error +checking by means of quitting the application if it runs out of memory. +This doesn't provide the best possible recovery from memory shortage, +but on the other hand it greatly simplifies the rest of the code, +because nothing else anywhere needs to worry about NULL returns from +allocation. + +5.2.1. snew() +------------- + + var = snew(type); + +This macro takes a single argument which is a _type name_. It allocates +space for one object of that type. If allocation fails it will call +fatal() and not return; so if it does return, you can be confident that +its return value is non-NULL. + +The return value is cast to the specified type, so that the compiler +will type-check it against the variable you assign it into. Thus, this +ensures you don't accidentally allocate memory the size of the wrong +type and assign it into a variable of the right one (or vice versa!). + +5.2.2. snewn() +-------------- + + var = snewn(n, type); + +This macro is the array form of snew(). It takes two arguments; the +first is a number, and the second is a type name. It allocates space +for that many objects of that type, and returns a type-checked non-NULL +pointer just as snew() does. + +5.2.3. sresize() +---------------- + + var = sresize(var, n, type); + +This macro is a type-checked form of realloc(). It takes three +arguments: an input memory block, a new size in elements, and a type. +It re-sizes the input memory block to a size sufficient to contain that +many elements of that type. It returns a type-checked non-NULL pointer, +like snew() and snewn(). + +The input memory block can be NULL, in which case this function will +behave exactly like snewn(). (In principle any ANSI-compliant realloc() +implementation ought to cope with this, but I've never quite trusted it +to work everywhere.) + +5.2.4. sfree() +-------------- + + void sfree(void *p); + +This function is pretty much equivalent to free(). It is provided with a +dynamically allocated block, and frees it. + +The input memory block can be NULL, in which case this function will do +nothing. (In principle any ANSI-compliant free() implementation ought to +cope with this, but I've never quite trusted it to work everywhere.) + +5.2.5. dupstr() +--------------- + + char *dupstr(const char *s); + +This function dynamically allocates a duplicate of a C string. Like the +snew() functions, it guarantees to return non-NULL or not return at all. + +(Many platforms provide the function strdup(). As well as guaranteeing +never to return NULL, my version has the advantage of being defined +_everywhere_, rather than inconveniently not quite everywhere.) + +5.2.6. free_cfg() +----------------- + + void free_cfg(config_item *cfg); + +This function correctly frees an array of `config_item's, including +walking the array until it gets to the end and freeing precisely those +`sval' fields which are expected to be dynamically allocated. + +(See section 2.3.8 for details of the `config_item' structure.) + +5.3. Sorted and counted tree functions +-------------------------------------- + +Many games require complex algorithms for generating random puzzles, and +some require moderately complex algorithms even during play. A common +requirement during these algorithms is for a means of maintaining sorted +or unsorted lists of items, such that items can be removed and added +conveniently. + +For general use, Puzzles provides the following set of functions which +maintain 2-3-4 trees in memory. (A 2-3-4 tree is a balanced tree +structure, with the property that all lookups, insertions, deletions, +splits and joins can be done in O(log N) time.) + +All these functions expect you to be storing a tree of `void *' +pointers. You can put anything you like in those pointers. + +By the use of per-node element counts, these tree structures have the +slightly unusual ability to look elements up by their numeric index +within the list represented by the tree. This means that they can be +used to store an unsorted list (in which case, every time you insert a +new element, you must explicitly specify the position where you wish to +insert it). They can also do numeric lookups in a sorted tree, which +might be useful for (for example) tracking the median of a changing data +set. + +As well as storing sorted lists, these functions can be used for storing +`maps' (associative arrays), by defining each element of a tree to be a +(key, value) pair. + +5.3.1. newtree234() +------------------- + + tree234 *newtree234(cmpfn234 cmp); + +Creates a new empty tree, and returns a pointer to it. + +The parameter `cmp' determines the sorting criterion on the tree. Its +prototype is + + typedef int (*cmpfn234)(void *, void *); + +If you want a sorted tree, you should provide a function matching this +prototype, which returns like strcmp() does (negative if the first +argument is smaller than the second, positive if it is bigger, zero if +they compare equal). In this case, the function addpos234() will not be +usable on your tree (because all insertions must respect the sorting +order). + +If you want an unsorted tree, pass NULL. In this case you will not be +able to use either add234() or del234(), or any other function such +as find234() which depends on a sorting order. Your tree will become +something more like an array, except that it will efficiently support +insertion and deletion as well as lookups by numeric index. + +5.3.2. freetree234() +-------------------- + + void freetree234(tree234 *t); + +Frees a tree. This function will not free the _elements_ of the tree +(because they might not be dynamically allocated, or you might be +storing the same set of elements in more than one tree); it will just +free the tree structure itself. If you want to free all the elements of +a tree, you should empty it before passing it to freetree234(), by means +of code along the lines of + + while ((element = delpos234(tree, 0)) != NULL) + sfree(element); /* or some more complicated free function */ + +5.3.3. add234() +--------------- + + void *add234(tree234 *t, void *e); + +Inserts a new element `e' into the tree `t'. This function expects the +tree to be sorted; the new element is inserted according to the sort +order. + +If an element comparing equal to `e' is already in the tree, then the +insertion will fail, and the return value will be the existing element. +Otherwise, the insertion succeeds, and `e' is returned. + +5.3.4. addpos234() +------------------ + + void *addpos234(tree234 *t, void *e, int index); + +Inserts a new element into an unsorted tree. Since there is no sorting +order to dictate where the new element goes, you must specify where you +want it to go. Setting `index' to zero puts the new element right at the +start of the list; setting `index' to the current number of elements in +the tree puts the new element at the end. + +Return value is `e', in line with add234() (although this function +cannot fail except by running out of memory, in which case it will bomb +out and die rather than returning an error indication). + +5.3.5. index234() +----------------- + + void *index234(tree234 *t, int index); + +Returns a pointer to the `index'th element of the tree, or NULL if +`index' is out of range. Elements of the tree are numbered from zero. + +5.3.6. find234() +---------------- + + void *find234(tree234 *t, void *e, cmpfn234 cmp); + +Searches for an element comparing equal to `e' in a sorted tree. + +If `cmp' is NULL, the tree's ordinary comparison function will be used +to perform the search. However, sometimes you don't want that; suppose, +for example, each of your elements is a big structure containing a +`char *' name field, and you want to find the element with a given name. +You _could_ achieve this by constructing a fake element structure, +setting its name field appropriately, and passing it to find234(), +but you might find it more convenient to pass _just_ a name string to +find234(), supplying an alternative comparison function which expects +one of its arguments to be a bare name and the other to be a large +structure containing a name field. + +Therefore, if `cmp' is not NULL, then it will be used to compare `e' to +elements of the tree. The first argument passed to `cmp' will always be +`e'; the second will be an element of the tree. + +(See section 5.3.1 for the definition of the `cmpfn234' function pointer +type.) + +The returned value is the element found, or NULL if the search is +unsuccessful. + +5.3.7. findrel234() +------------------- + + void *findrel234(tree234 *t, void *e, cmpfn234 cmp, int relation); + +This function is like find234(), but has the additional ability to do a +_relative_ search. The additional parameter `relation' can be one of the +following values: + +REL234_EQ + + Find only an element that compares equal to `e'. This is exactly the + behaviour of find234(). + +REL234_LT + + Find the greatest element that compares strictly less than `e'. `e' + may be NULL, in which case it finds the greatest element in the + whole tree (which could also be done by index234(t, count234(t)-1)). + +REL234_LE + + Find the greatest element that compares less than or equal to `e'. + (That is, find an element that compares equal to `e' if possible, + but failing that settle for something just less than it.) + +REL234_GT + + Find the smallest element that compares strictly greater than `e'. + `e' may be NULL, in which case it finds the smallest element in the + whole tree (which could also be done by index234(t, 0)). + +REL234_GE + + Find the smallest element that compares greater than or equal + to `e'. (That is, find an element that compares equal to `e' if + possible, but failing that settle for something just bigger than + it.) + +Return value, as before, is the element found or NULL if no element +satisfied the search criterion. + +5.3.8. findpos234() +------------------- + + void *findpos234(tree234 *t, void *e, cmpfn234 cmp, int *index); + +This function is like find234(), but has the additional feature of +returning the index of the element found in the tree; that index is +written to `*index' in the event of a successful search (a non-NULL +return value). + +`index' may be NULL, in which case this function behaves exactly like +find234(). + +5.3.9. findrelpos234() +---------------------- + + void *findrelpos234(tree234 *t, void *e, cmpfn234 cmp, int relation, + int *index); + +This function combines all the features of findrel234() and +findpos234(). + +5.3.10. del234() +---------------- + + void *del234(tree234 *t, void *e); + +Finds an element comparing equal to `e' in the tree, deletes it, and +returns it. + +The input tree must be sorted. + +The element found might be `e' itself, or might merely compare equal to +it. + +Return value is NULL if no such element is found. + +5.3.11. delpos234() +------------------- + + void *delpos234(tree234 *t, int index); + +Deletes the element at position `index' in the tree, and returns it. + +Return value is NULL if the index is out of range. + +5.3.12. count234() +------------------ + + int count234(tree234 *t); + +Returns the number of elements currently in the tree. + +5.3.13. splitpos234() +--------------------- + + tree234 *splitpos234(tree234 *t, int index, int before); + +Splits the input tree into two pieces at a given position, and creates a +new tree containing all the elements on one side of that position. + +If `before' is TRUE, then all the items at or after position `index' are +left in the input tree, and the items before that point are returned in +the new tree. Otherwise, the reverse happens: all the items at or after +`index' are moved into the new tree, and those before that point are +left in the old one. + +If `index' is equal to 0 or to the number of elements in the input tree, +then one of the two trees will end up empty (and this is not an error +condition). If `index' is further out of range in either direction, the +operation will fail completely and return NULL. + +This operation completes in O(log N) time, no matter how large the tree +or how balanced or unbalanced the split. + +5.3.14. split234() +------------------ + + tree234 *split234(tree234 *t, void *e, cmpfn234 cmp, int rel); + +Splits a sorted tree according to its sort order. + +`rel' can be any of the relation constants described in section 5.3.7, +_except_ for REL234_EQ. All the elements having that relation to `e' +will be transferred into the new tree; the rest will be left in the old +one. + +The parameter `cmp' has the same semantics as it does in find234(): if +it is not NULL, it will be used in place of the tree's own comparison +function when comparing elements to `e', in such a way that `e' itself +is always the first of its two operands. + +Again, this operation completes in O(log N) time, no matter how large +the tree or how balanced or unbalanced the split. + +5.3.15. join234() +----------------- + + tree234 *join234(tree234 *t1, tree234 *t2); + +Joins two trees together by concatenating the lists they represent. All +the elements of `t2' are moved into `t1', in such a way that they appear +_after_ the elements of `t1'. The tree `t2' is freed; the return value +is `t1'. + +If you apply this function to a sorted tree and it violates the sort +order (i.e. the smallest element in `t2' is smaller than or equal to the +largest element in `t1'), the operation will fail and return NULL. + +This operation completes in O(log N) time, no matter how large the trees +being joined together. + +5.3.16. join234r() +------------------ + + tree234 *join234r(tree234 *t1, tree234 *t2); + +Joins two trees together in exactly the same way as join234(), but this +time the combined tree is returned in `t2', and `t1' is destroyed. The +elements in `t1' still appear before those in `t2'. + +Again, this operation completes in O(log N) time, no matter how large +the trees being joined together. + +5.3.17. copytree234() +--------------------- + + tree234 *copytree234(tree234 *t, copyfn234 copyfn, + void *copyfnstate); + +Makes a copy of an entire tree. + +If `copyfn' is NULL, the tree will be copied but the elements will not +be; i.e. the new tree will contain pointers to exactly the same physical +elements as the old one. + +If you want to copy each actual element during the operation, you can +instead pass a function in `copyfn' which makes a copy of each element. +That function has the prototype + + typedef void *(*copyfn234)(void *state, void *element); + +and every time it is called, the `state' parameter will be set to the +value you passed in as `copyfnstate'. + +5.4. Miscellaneous utility functions and macros +----------------------------------------------- + +This section contains all the utility functions which didn't sensibly +fit anywhere else. + +5.4.1. TRUE and FALSE +--------------------- + +The main Puzzles header file defines the macros TRUE and FALSE, which +are used throughout the code in place of 0 and 1 to indicate that the +values are in a boolean context. For code base consistency, I'd prefer +it if submissions of new code followed this convention as well. + +5.4.2. max() and min() +---------------------- + +The main Puzzles header file defines the pretty standard macros max() +and min(), each of which is given two arguments and returns the one +which compares greater or less respectively. + +These macros may evaluate their arguments multiple times. Avoid side +effects. + +5.4.3. PI +--------- + +The main Puzzles header file defines a macro PI which expands to a +floating-point constant representing pi. + +(I've never understood why ANSI's doesn't define this. It'd be +so useful!) + +5.4.4. obfuscate_bitmap() +------------------------- + + void obfuscate_bitmap(unsigned char *bmp, int bits, int decode); + +This function obscures the contents of a piece of data, by cryptographic +methods. It is useful for games of hidden information (such as Mines, +Guess or Black Box), in which the game ID theoretically reveals all the +information the player is supposed to be trying to guess. So in order +that players should be able to send game IDs to one another without +accidentally spoiling the resulting game by looking at them, these games +obfuscate their game IDs using this function. + +Although the obfuscation function is cryptographic, it cannot properly +be called encryption because it has no key. Therefore, anybody motivated +enough can re-implement it, or hack it out of the Puzzles source, +and strip the obfuscation off one of these game IDs to see what lies +beneath. (Indeed, they could usually do it much more easily than that, +by entering the game ID into their own copy of the puzzle and hitting +Solve.) The aim is not to protect against a determined attacker; the aim +is simply to protect people who wanted to play the game honestly from +_accidentally_ spoiling their own fun. + +The input argument `bmp' points at a piece of memory to be obfuscated. +`bits' gives the length of the data. Note that that length is in _bits_ +rather than bytes: if you ask for obfuscation of a partial number of +bytes, then you will get it. Bytes are considered to be used from the +top down: thus, for example, setting `bits' to 10 will cover the whole +of bmp[0] and the _top two_ bits of bmp[1]. The remainder of a partially +used byte is undefined (i.e. it may be corrupted by the function). + +The parameter `decode' is FALSE for an encoding operation, and TRUE +for a decoding operation. Each is the inverse of the other. (There's +no particular reason you shouldn't obfuscate by decoding and restore +cleartext by encoding, if you really wanted to; it should still work.) + +The input bitmap is processed in place. + +5.4.5. bin2hex() +---------------- + + char *bin2hex(const unsigned char *in, int inlen); + +This function takes an input byte array and converts it into an +ASCII string encoding those bytes in (lower-case) hex. It returns a +dynamically allocated string containing that encoding. + +This function is useful for encoding the result of obfuscate_bitmap() in +printable ASCII for use in game IDs. + +5.4.6. hex2bin() +---------------- + + unsigned char *hex2bin(const char *in, int outlen); + +This function takes an ASCII string containing hex digits, and converts +it back into a byte array of length `outlen'. If there aren't enough +hex digits in the string, the contents of the resulting array will be +undefined. + +This function is the inverse of bin2hex(). + +5.4.7. game_mkhighlight() +------------------------- + + void game_mkhighlight(frontend *fe, float *ret, + int background, int highlight, int lowlight); + +It's reasonably common for a puzzle game's graphics to use highlights +and lowlights to indicate `raised' or `lowered' sections. Fifteen, +Sixteen and Twiddle are good examples of this. + +Puzzles using this graphical style are running a risk if they just use +whatever background colour is supplied to them by the front end, because +that background colour might be too light to see any highlights on at +all. (In particular, it's not unheard of for the front end to specify a +default background colour of white.) + +Therefore, such puzzles can call this utility function from their +colours() routine (section 2.8.6). You pass it your front end handle, a +pointer to the start of your return array, and three colour indices. It +will: + + - call frontend_default_colour() (section 4.30) to fetch the front + end's default background colour + + - alter the brightness of that colour if it's unsuitable + + - define brighter and darker variants of the colour to be used as + highlights and lowlights + + - write those results into the relevant positions in the `ret' array. + +Thus, ret[background*3] to ret[background*3+2] will be set to RGB values +defining a sensible background colour, and similary `highlight' and +`lowlight' will be set to sensible colours. + +6. How to write a new puzzle +---------------------------- + +This chapter gives a guide to how to actually write a new puzzle: where +to start, what to do first, how to solve common problems. + +The previous chapters have been largely composed of facts. This one is +mostly advice. + +6.1. Choosing a puzzle +---------------------- + +Before you start writing a puzzle, you have to choose one. Your taste +in puzzle games is up to you, of course; and, in fact, you're probably +reading this guide because you've _already_ thought of a game you want +to write. But if you want to get it accepted into the official Puzzles +distribution, then there's a criterion it has to meet. + +The current Puzzles editorial policy is that all games should be _fair_. +A fair game is one which a player can only fail to complete through +demonstrable lack of skill - that is, such that a better player in the +same situation would have _known_ to do something different. + +For a start, that means every game presented to the user must have _at +least one solution_. Giving the unsuspecting user a puzzle which is +actually impossible is not acceptable. (There is an exception: if the +user has selected some non-default option which is clearly labelled as +potentially unfair, _then_ you're allowed to generate possibly insoluble +puzzles, because the user isn't unsuspecting any more. Same Game and +Mines both have options of this type.) + +Also, this actually _rules out_ games such as Klondike, or the normal +form of Mahjong Solitaire. Those games have the property that even if +there is a solution (i.e. some sequence of moves which will get from +the start state to the solved state), the player doesn't necessarily +have enough information to _find_ that solution. In both games, it is +possible to reach a dead end because you had an arbitrary choice to make +and made it the wrong way. This violates the fairness criterion, because +a better player couldn't have known they needed to make the other +choice. + +(GNOME has a variant on Mahjong Solitaire which makes it fair: there +is a Shuffle operation which randomly permutes all the remaining tiles +without changing their positions, which allows you to get out of a +sticky situation. Using this operation adds a 60-second penalty to your +solution time, so it's to the player's advantage to try to minimise +the chance of having to use it. It's still possible to render the game +uncompletable if you end up with only two tiles vertically stacked, +but that's easy to foresee and avoid using a shuffle operation. This +form of the game _is_ fair. Implementing it in Puzzles would require +an infrastructure change so that the back end could communicate time +penalties to the mid-end, but that would be easy enough.) + +Providing a _unique_ solution is a little more negotiable; it depends +on the puzzle. Solo would have been of unacceptably low quality if it +didn't always have a unique solution, whereas Twiddle inherently has +multiple solutions by its very nature and it would have been meaningless +to even _suggest_ making it uniquely soluble. Somewhere in between, Flip +could reasonably be made to have unique solutions (by enforcing a zero- +dimension kernel in every generated matrix) but it doesn't seem like a +serious quality problem that it doesn't. + +Of course, you don't _have_ to care about all this. There's nothing +stopping you implementing any puzzle you want to if you're happy to +maintain your puzzle yourself, distribute it from your own web site, +fork the Puzzles code completely, or anything like that. It's free +software; you can do what you like with it. But any game that you want +to be accepted into _my_ Puzzles code base has to satisfy the fairness +criterion, which means all randomly generated puzzles must have a +solution (unless the user has deliberately chosen otherwise) and it must +be possible _in theory_ to find that solution without having to guess. + +6.2. Getting started +-------------------- + +The simplest way to start writing a new puzzle is to copy `nullgame.c'. +This is a template puzzle source file which does almost nothing, but +which contains all the back end function prototypes and declares the +back end data structure correctly. It is built every time the rest of +Puzzles is built, to ensure that it doesn't get out of sync with the +code and remains buildable. + +So start by copying `nullgame.c' into your new source file. Then you'll +gradually add functionality until the very boring Null Game turns into +your real game. + +Next you'll need to add your puzzle to the Makefiles, in order to +compile it conveniently. _Do not edit the Makefiles_: they are created +automatically by the script `mkfiles.pl', from the file called `Recipe'. +Edit `Recipe', and then re-run `mkfiles.pl'. + +Once your source file is building, you can move on to the fun bit. + +6.2.1. Puzzle generation +------------------------ + +Randomly generating instances of your puzzle is almost certain to be +the most difficult part of the code, and also the task with the highest +chance of turning out to be completely infeasible. Therefore I strongly +recommend doing it _first_, so that if it all goes horribly wrong you +haven't wasted any more time than you absolutely had to. What I usually +do is to take an unmodified `nullgame.c', and start adding code to +new_game_desc() which tries to generate a puzzle instance and print it +out using printf(). Once that's working, _then_ I start connecting it up +to the return value of new_game_desc(), populating other structures like +`game_params', and generally writing the rest of the source file. + +There are many ways to generate a puzzle which is known to be soluble. +In this section I list all the methods I currently know of, in case any +of them can be applied to your puzzle. (Not all of these methods will +work, or in some cases even make sense, for all puzzles.) + +Some puzzles are mathematically tractable, meaning you can work out in +advance which instances are soluble. Sixteen, for example, has a parity +constraint in some settings which renders exactly half the game space +unreachable, but it can be mathematically proved that any position +not in that half _is_ reachable. Therefore, Sixteen's grid generation +simply consists of selecting at random from a well defined subset of the +game space. Cube in its default state is even easier: _every_ possible +arrangement of the blue squares and the cube's starting position is +soluble! + +Another option is to redefine what you mean by `soluble'. Black Box +takes this approach. There are layouts of balls in the box which are +completely indistinguishable from one another no matter how many beams +you fire into the box from which angles, which would normally be grounds +for declaring those layouts unfair; but fortunately, detecting that +indistinguishability is computationally easy. So Black Box doesn't +demand that your ball placements match its own; it merely demands +that your ball placements be _indistinguishable_ from the ones it was +thinking of. If you have an ambiguous puzzle, then any of the possible +answers is considered to be a solution. Having redefined the rules in +that way, any puzzle is soluble again. + +Those are the simple techniques. If they don't work, you have to get +cleverer. + +One way to generate a soluble puzzle is to start from the solved state +and make inverse moves until you reach a starting state. Then you know +there's a solution, because you can just list the inverse moves you made +and make them in the opposite order to return to the solved state. + +This method can be simple and effective for puzzles where you get to +decide what's a starting state and what's not. In Pegs, for example, +the generator begins with one peg in the centre of the board and makes +inverse moves until it gets bored; in this puzzle, valid inverse moves +are easy to detect, and _any_ state that's reachable from the solved +state by inverse moves is a reasonable starting position. So Pegs just +continues making inverse moves until the board satisfies some criteria +about extent and density, and then stops and declares itself done. + +For other puzzles, it can be a lot more difficult. Same Game uses +this strategy too, and it's lucky to get away with it at all: valid +inverse moves aren't easy to find (because although it's easy to insert +additional squares in a Same Game position, it's difficult to arrange +that _after_ the insertion they aren't adjacent to any other squares of +the same colour), so you're constantly at risk of running out of options +and having to backtrack or start again. Also, Same Game grids never +start off half-empty, which means you can't just stop when you run out +of moves - you have to find a way to fill the grid up _completely_. + +The other way to generate a puzzle that's soluble is to start from the +other end, and actually write a _solver_. This tends to ensure that a +puzzle has a _unique_ solution over and above having a solution at all, +so it's a good technique to apply to puzzles for which that's important. + +One theoretical drawback of generating soluble puzzles by using a solver +is that your puzzles are restricted in difficulty to those which the +solver can handle. (Most solvers are not fully general: many sets of +puzzle rules are NP-complete or otherwise nasty, so most solvers can +only handle a subset of the theoretically soluble puzzles.) It's been +my experience in practice, however, that this usually isn't a problem; +computers are good at very different things from humans, and what the +computer thinks is nice and easy might still be pleasantly challenging +for a human. For example, when solving Dominosa puzzles I frequently +find myself using a variety of reasoning techniques that my solver +doesn't know about; in principle, therefore, I should be able to solve +the puzzle using only those techniques it _does_ know about, but this +would involve repeatedly searching the entire grid for the one simple +deduction I can make. Computers are good at this sort of exhaustive +search, but it's been my experience that human solvers prefer to do more +complex deductions than to spend ages searching for simple ones. So in +many cases I don't find my own playing experience to be limited by the +restrictions on the solver. + +(This isn't _always_ the case. Solo is a counter-example; generating +Solo puzzles using a simple solver does lead to qualitatively easier +puzzles. Therefore I had to make the Solo solver rather more advanced +than most of them.) + +There are several different ways to apply a solver to the problem of +generating a soluble puzzle. I list a few of them below. + +The simplest approach is brute force: randomly generate a puzzle, use +the solver to see if it's soluble, and if not, throw it away and try +again until you get lucky. This is often a viable technique if all +else fails, but it tends not to scale well: for many puzzle types, the +probability of finding a uniquely soluble instance decreases sharply +as puzzle size goes up, so this technique might work reasonably fast +for small puzzles but take (almost) forever at larger sizes. Still, if +there's no other alternative it can be usable: Pattern and Dominosa +both use this technique. (However, Dominosa has a means of tweaking the +randomly generated grids to increase the _probability_ of them being +soluble, by ruling out one of the most common ambiguous cases. This +improved generation speed by over a factor of 10 on the highest preset!) + +An approach which can be more scalable involves generating a grid and +then tweaking it to make it soluble. This is the technique used by Mines +and also by Net: first a random puzzle is generated, and then the solver +is run to see how far it gets. Sometimes the solver will get stuck; +when that happens, examine the area it's having trouble with, and make +a small random change in that area to allow it to make more progress. +Continue solving (possibly even without restarting the solver), tweaking +as necessary, until the solver finishes. Then restart the solver from +the beginning to ensure that the tweaks haven't caused new problems in +the process of solving old ones (which can sometimes happen). + +This strategy works well in situations where the usual solver failure +mode is to get stuck in an easily localised spot. Thus it works well +for Net and Mines, whose most common failure mode tends to be that most +of the grid is fine but there are a few widely separated ambiguous +sections; but it would work less well for Dominosa, in which the way you +get stuck is to have scoured the whole grid and not found anything you +can deduce _anywhere_. Also, it relies on there being a low probability +that tweaking the grid introduces a new problem at the same time as +solving the old one; Mines and Net also have the property that most of +their deductions are local, so that it's very unlikely for a tweak to +affect something half way across the grid from the location where it was +applied. In Dominosa, by contrast, a lot of deductions use information +about half the grid (`out of all the sixes, only one is next to a +three', which can depend on the values of up to 32 of the 56 squares in +the default setting!), so this tweaking strategy would be rather less +likely to work well. + +A more specialised strategy is that used in Solo and Slant. These +puzzles have the property that they derive their difficulty from not +presenting all the available clues. (In Solo's case, if all the possible +clues were provided then the puzzle would already be solved; in Slant +it would still require user action to fill in the lines, but it would +present no challenge at all). Therefore, a simple generation technique +is to leave the decision of which clues to provide until the last +minute. In other words, first generate a random _filled_ grid with all +possible clues present, and then gradually remove clues for as long as +the solver reports that it's still soluble. Unlike the methods described +above, this technique _cannot_ fail - once you've got a filled grid, +nothing can stop you from being able to convert it into a viable puzzle. +However, it wouldn't even be meaningful to apply this technique to (say) +Pattern, in which clues can never be left out, so the only way to affect +the set of clues is by altering the solution. + +(Unfortunately, Solo is complicated by the need to provide puzzles at +varying difficulty levels. It's easy enough to generate a puzzle of +_at most_ a given level of difficulty; you just have a solver with +configurable intelligence, and you set it to a given level and apply the +above technique, thus guaranteeing that the resulting grid is solvable +by someone with at most that much intelligence. However, generating a +puzzle of _at least_ a given level of difficulty is rather harder; if +you go for _at most_ Intermediate level, you're likely to find that +you've accidentally generated a Trivial grid a lot of the time, because +removing just one number is sufficient to take the puzzle from Trivial +straight to Ambiguous. In that situation Solo has no remaining options +but to throw the puzzle away and start again.) + +A final strategy is to use the solver _during_ puzzle construction: +lay out a bit of the grid, run the solver to see what it allows you to +deduce, and then lay out a bit more to allow the solver to make more +progress. There are articles on the web that recommend constructing +Sudoku puzzles by this method (which is completely the opposite way +round to how Solo does it); for Sudoku it has the advantage that you +get to specify your clue squares in advance (so you can have them make +pretty patterns). + +Rectangles uses a strategy along these lines. First it generates a grid +by placing the actual rectangles; then it has to decide where in each +rectangle to place a number. It uses a solver to help it place the +numbers in such a way as to ensure a unique solution. It does this by +means of running a test solver, but it runs the solver _before_ it's +placed any of the numbers - which means the solver must be capable of +coping with uncertainty about exactly where the numbers are! It runs +the solver as far as it can until it gets stuck; then it narrows down +the possible positions of a number in order to allow the solver to make +more progress, and so on. Most of the time this process terminates with +the grid fully solved, at which point any remaining number-placement +decisions can be made at random from the options not so far ruled out. +Note that unlike the Net/Mines tweaking strategy described above, this +algorithm does not require a checking run after it completes: if it +finishes successfully at all, then it has definitely produced a uniquely +soluble puzzle. + +Most of the strategies described above are not 100% reliable. Each +one has a failure rate: every so often it has to throw out the whole +grid and generate a fresh one from scratch. (Solo's strategy would +be the exception, if it weren't for the need to provide configurable +difficulty levels.) Occasional failures are not a fundamental problem in +this sort of work, however: it's just a question of dividing the grid +generation time by the success rate (if it takes 10ms to generate a +candidate grid and 1/5 of them work, then it will take 50ms on average +to generate a viable one), and seeing whether the expected time taken +to _successfully_ generate a puzzle is unacceptably slow. Dominosa's +generator has a very low success rate (about 1 out of 20 candidate grids +turn out to be usable, and if you think _that's_ bad then go and look +at the source code and find the comment showing what the figures were +before the generation-time tweaks!), but the generator itself is very +fast so this doesn't matter. Rectangles has a slower generator, but +fails well under 50% of the time. + +So don't be discouraged if you have an algorithm that doesn't always +work: if it _nearly_ always works, that's probably good enough. The one +place where reliability is important is that your algorithm must never +produce false positives: it must not claim a puzzle is soluble when it +isn't. It can produce false negatives (failing to notice that a puzzle +is soluble), and it can fail to generate a puzzle at all, provided it +doesn't do either so often as to become slow. + +One last piece of advice: for grid-based puzzles, when writing and +testing your generation algorithm, it's almost always a good idea _not_ +to test it initially on a grid that's square (i.e. w==h), because if the +grid is square then you won't notice if you mistakenly write `h' instead +of `w' (or vice versa) somewhere in the code. Use a rectangular grid for +testing, and any size of grid will be likely to work after that. + +6.2.2. Designing textual description formats +-------------------------------------------- + +Another aspect of writing a puzzle which is worth putting some thought +into is the design of the various text description formats: the format +of the game parameter encoding, the game description encoding, and the +move encoding. + +The first two of these should be reasonably intuitive for a user to type +in; so provide some flexibility where possible. Suppose, for example, +your parameter format consists of two numbers separated by an `x' to +specify the grid dimensions (`10x10' or `20x15'), and then has some +suffixes to specify other aspects of the game type. It's almost always a +good idea in this situation to arrange that decode_params() can handle +the suffixes appearing in any order, even if encode_params() only ever +generates them in one order. + +These formats will also be expected to be reasonably stable: users will +expect to be able to exchange game IDs with other users who aren't +running exactly the same version of your game. So make them robust and +stable: don't build too many assumptions into the game ID format which +will have to be changed every time something subtle changes in the +puzzle code. + +6.3. Common how-to questions +---------------------------- + +This section lists some common things people want to do when writing a +puzzle, and describes how to achieve them within the Puzzles framework. + +6.3.1. Drawing objects at only one position +------------------------------------------- + +A common phenomenon is to have an object described in the `game_state' +or the `game_ui' which can only be at one position. A cursor - probably +specified in the `game_ui' - is a good example. + +In the `game_ui', it would _obviously_ be silly to have an array +covering the whole game grid with a boolean flag stating whether the +cursor was at each position. Doing that would waste space, would make +it difficult to find the cursor in order to do anything with it, and +would introduce the potential for synchronisation bugs in which you +ended up with two cursors or none. The obviously sensible way to store a +cursor in the `game_ui' is to have fields directly encoding the cursor's +coordinates. + +However, it is a mistake to assume that the same logic applies to the +`game_drawstate'. If you replicate the cursor position fields in the +draw state, the redraw code will get very complicated. In the draw +state, in fact, it _is_ probably the right thing to have a cursor flag +for every position in the grid. You probably have an array for the whole +grid in the drawstate already (stating what is currently displayed in +the window at each position); the sensible approach is to add a `cursor' +flag to each element of that array. Then the main redraw loop will look +something like this (pseudo-code): + + for (y = 0; y < h; y++) { + for (x = 0; x < w; x++) { + int value = state->symbol_at_position[y][x]; + if (x == ui->cursor_x && y == ui->cursor_y) + value |= CURSOR; + if (ds->symbol_at_position[y][x] != value) { + symbol_drawing_subroutine(dr, ds, x, y, value); + ds->symbol_at_position[y][x] = value; + } + } + } + +This loop is very simple, pretty hard to get wrong, and _automatically_ +deals both with erasing the previous cursor and drawing the new one, +with no special case code required. + +This type of loop is generally a sensible way to write a redraw +function, in fact. The best thing is to ensure that the information +stored in the draw state for each position tells you _everything_ about +what was drawn there. A good way to ensure that is to pass precisely +the same information, and _only_ that information, to a subroutine that +does the actual drawing; then you know there's no additional information +which affects the drawing but which you don't notice changes in. + +6.3.2. Implementing a keyboard-controlled cursor +------------------------------------------------ + +It is often useful to provide a keyboard control method in a basically +mouse-controlled game. A keyboard-controlled cursor is best implemented +by storing its location in the `game_ui' (since if it were in the +`game_state' then the user would have to separately undo every cursor +move operation). So the procedure would be: + + - Put cursor position fields in the `game_ui'. + + - interpret_move() responds to arrow keys by modifying the cursor + position fields and returning "". + + - interpret_move() responds to some sort of fire button by actually + performing a move based on the current cursor location. + + - You might want an additional `game_ui' field stating whether the + cursor is currently visible, and having it disappear when a mouse + action occurs (so that it doesn't clutter the display when not + actually in use). + + - You might also want to automatically hide the cursor in + changed_state() when the current game state changes to one in + which there is no move to make (which is the case in some types of + completed game). + + - redraw() draws the cursor using the technique described in section + 6.3.1. + +6.3.3. Implementing draggable sprites +------------------------------------- + +Some games have a user interface which involves dragging some sort of +game element around using the mouse. If you need to show a graphic +moving smoothly over the top of other graphics, use a blitter (see +section 3.1.11 for the blitter API) to save the background underneath +it. The typical scenario goes: + + - Have a blitter field in the `game_drawstate'. + + - Set the blitter field to NULL in the game's new_drawstate() + function, since you don't yet know how big the piece of saved + background needs to be. + + - In the game's set_size() function, once you know the size of the + object you'll be dragging around the display and hence the required + size of the blitter, actually allocate the blitter. + + - In free_drawstate(), free the blitter if it's not NULL. + + - In interpret_move(), respond to mouse-down and mouse-drag events by + updating some fields in the game_ui which indicate that a drag is in + progress. + + - At the _very end_ of redraw(), after all other drawing has been + done, draw the moving object if there is one. First save the + background under the object in the blitter; then set a clip + rectangle covering precisely the area you just saved (just in case + anti-aliasing or some other error causes your drawing to go beyond + the area you saved). Then draw the object, and call unclip(). + Finally, set a flag in the game_drawstate that indicates that the + blitter needs restoring. + + - At the very start of redraw(), before doing anything else at all, + check the flag in the game_drawstate, and if it says the blitter + needs restoring then restore it. (Then clear the flag, so that this + won't happen again in the next redraw if no moving object is drawn + this time.) + +This way, you will be able to write the rest of the redraw function +completely ignoring the dragged object, as if it were floating above +your bitmap and being completely separate. + +6.3.4. Sharing large invariant data between all game states +----------------------------------------------------------- + +In some puzzles, there is a large amount of data which never changes +between game states. The array of numbers in Dominosa is a good example. + +You _could_ dynamically allocate a copy of that array in every +`game_state', and have dup_game() make a fresh copy of it for every new +`game_state'; but it would waste memory and time. A more efficient way +is to use a reference-counted structure. + + - Define a structure type containing the data in question, and also + containing an integer reference count. + + - Have a field in `game_state' which is a pointer to this structure. + + - In new_game(), when creating a fresh game state at the start of a + new game, create an instance of this structure, initialise it with + the invariant data, and set its reference count to 1. + + - In dup_game(), rather than making a copy of the structure for the + new game state, simply set the new game state to point at the same + copy of the structure, and increment its reference count. + + - In free_game(), decrement the reference count in the structure + pointed to by the game state; if the count reaches zero, free the + structure. + +This way, the invariant data will persist for only as long as it's +genuinely needed; _as soon_ as the last game state for a particular +puzzle instance is freed, the invariant data for that puzzle will +vanish as well. Reference counting is a very efficient form of garbage +collection, when it works at all. (Which it does in this instance, of +course, because there's no possibility of circular references.) + +6.3.5. Implementing multiple types of flash +------------------------------------------- + +In some games you need to flash in more than one different way. Mines, +for example, flashes white when you win, and flashes red when you tread +on a mine and die. + +The simple way to do this is: + + - Have a field in the `game_ui' which describes the type of flash. + + - In flash_length(), examine the old and new game states to decide + whether a flash is required and what type. Write the type of flash + to the `game_ui' field whenever you return non-zero. + + - In redraw(), when you detect that `flash_time' is non-zero, examine + the field in `game_ui' to decide which type of flash to draw. + +redraw() will never be called with `flash_time' non-zero unless +flash_length() was first called to tell the mid-end that a flash was +required; so whenever redraw() notices that `flash_time' is non-zero, +you can be sure that the field in `game_ui' is correctly set. + +6.3.6. Animating game moves +--------------------------- + +A number of puzzle types benefit from a quick animation of each move you +make. + +For some games, such as Fifteen, this is particularly easy. Whenever +redraw() is called with `oldstate' non-NULL, Fifteen simply compares the +position of each tile in the two game states, and if the tile is not in +the same place then it draws it some fraction of the way from its old +position to its new position. This method copes automatically with undo. + +Other games are less obvious. In Sixteen, for example, you can't just +draw each tile a fraction of the way from its old to its new position: +if you did that, the end tile would zip very rapidly past all the others +to get to the other end and that would look silly. (Worse, it would look +inconsistent if the end tile was drawn on top going one way and on the +bottom going the other way.) + +A useful trick here is to define a field or two in the game state that +indicates what the last move was. + + - Add a `last move' field to the `game_state' (or two or more fields + if the move is complex enough to need them). + + - new_game() initialises this field to a null value for a new game + state. + + - execute_move() sets up the field to reflect the move it just + performed. + + - redraw() now needs to examine its `dir' parameter. If `dir' is + positive, it determines the move being animated by looking at the + last-move field in `newstate'; but if `dir' is negative, it has to + look at the last-move field in `oldstate', and invert whatever move + it finds there. + +Note also that Sixteen needs to store the _direction_ of the move, +because you can't quite determine it by examining the row or column in +question. You can in almost all cases, but when the row is precisely +two squares long it doesn't work since a move in either direction looks +the same. (You could argue that since moving a 2-element row left and +right has the same effect, it doesn't matter which one you animate; but +in fact it's very disorienting to click the arrow left and find the row +moving right, and almost as bad to undo a move to the right and find the +game animating _another_ move to the right.) + +6.3.7. Animating drag operations +-------------------------------- + +In Untangle, moves are made by dragging a node from an old position to a +new position. Therefore, at the time when the move is initially made, it +should not be animated, because the node has already been dragged to the +right place and doesn't need moving there. However, it's nice to animate +the same move if it's later undone or redone. This requires a bit of +fiddling. + +The obvious approach is to have a flag in the `game_ui' which inhibits +move animation, and to set that flag in interpret_move(). The question +is, when would the flag be reset again? The obvious place to do so +is changed_state(), which will be called once per move. But it will +be called _before_ anim_length(), so if it resets the flag then +anim_length() will never see the flag set at all. + +The solution is to have _two_ flags in a queue. + + - Define two flags in `game_ui'; let's call them `current' and `next'. + + - Set both to FALSE in `new_ui()'. + + - When a drag operation completes in interpret_move(), set the `next' + flag to TRUE. + + - Every time changed_state() is called, set the value of `current' to + the value in `next', and then set the value of `next' to FALSE. + + - That way, `current' will be TRUE _after_ a call to changed_state() + if and only if that call to changed_state() was the result of a + drag operation processed by interpret_move(). Any other call to + changed_state(), due to an Undo or a Redo or a Restart or a Solve, + will leave `current' FALSE. + + - So now anim_length() can request a move animation if and only if the + `current' flag is _not_ set. + +6.3.8. Inhibiting the victory flash when Solve is used +------------------------------------------------------ + +Many games flash when you complete them, as a visual congratulation for +having got to the end of the puzzle. It often seems like a good idea to +disable that flash when the puzzle is brought to a solved state by means +of the Solve operation. + +This is easily done: + + - Add a `cheated' flag to the `game_state'. + + - Set this flag to FALSE in new_game(). + + - Have solve() return a move description string which clearly + identifies the move as a solve operation. + + - Have execute_move() respond to that clear identification by setting + the `cheated' flag in the returned `game_state'. The flag will + then be propagated to all subsequent game states, even if the user + continues fiddling with the game after it is solved. + + - flash_length() now returns non-zero if `oldstate' is not completed + and `newstate' is, _and_ neither state has the `cheated' flag set. + +6.4. Things to test once your puzzle is written +----------------------------------------------- + +Puzzle implementations written in this framework are self-testing as far +as I could make them. + +Textual game and move descriptions, for example, are generated and +parsed as part of the normal process of play. Therefore, if you can make +moves in the game _at all_ you can be reasonably confident that the +mid-end serialisation interface will function correctly and you will +be able to save your game. (By contrast, if I'd stuck with a single +make_move() function performing the jobs of both interpret_move() and +execute_move(), and had separate functions to encode and decode a game +state in string form, then those functions would not be used during +normal play; so they could have been completely broken, and you'd never +know it until you tried to save the game - which would have meant you'd +have to test game saving _extensively_ and make sure to test every +possible type of game state. As an added bonus, doing it the way I did +leads to smaller save files.) + +There is one exception to this, which is the string encoding of the +`game_ui'. Most games do not store anything permanent in the `game_ui', +and hence do not need to put anything in its encode and decode +functions; but if there is anything in there, you do need to test game +loading and saving to ensure those functions work properly. + +It's also worth testing undo and redo of all operations, to ensure that +the redraw and the animations (if any) work properly. Failing to animate +undo properly seems to be a common error. + +Other than that, just use your common sense. + diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..efb905f --- /dev/null +++ b/Makefile @@ -0,0 +1,304 @@ +# Makefile for puzzles under X/GTK and Unix. +# +# This file was created by `mkfiles.pl' from the `Recipe' file. +# DO NOT EDIT THIS FILE DIRECTLY; edit Recipe or mkfiles.pl instead. + +# You can define this path to point at your tools if you need to +# TOOLPATH = /opt/gcc/bin +CC = $(TOOLPATH)cc +# You can manually set this to `gtk-config' or `pkg-config gtk+-1.2' +# (depending on what works on your system) if you want to enforce +# building with GTK 1.2, or you can set it to `pkg-config gtk+-2.0' +# if you want to enforce 2.0. The default is to try 2.0 and fall back +# to 1.2 if it isn't found. +GTK_CONFIG = sh -c 'pkg-config gtk+-2.0 $$0 2>/dev/null || gtk-config $$0' + +CFLAGS = -O2 -Wall -Werror -g -I./ `$(GTK_CONFIG) --cflags` +XLDFLAGS = `$(GTK_CONFIG) --libs` +ULDFLAGS =# +INSTALL=install +INSTALL_PROGRAM=$(INSTALL) +INSTALL_DATA=$(INSTALL) +prefix=/usr/local +exec_prefix=$(prefix) +bindir=$(exec_prefix)/bin +gamesdir=$(exec_prefix)/games +mandir=$(prefix)/man +man1dir=$(mandir)/man1 + +all: blackbox bridges cube dominosa fifteen flip guess inertia lightup \ + lightupsolver loopy map mapsolver mineobfusc mines net \ + netslide nullgame pattern patternsolver pegs rect samegame \ + sixteen slant slantsolver solo solosolver tents tentssolver \ + twiddle untangle + +blackbox: blackbox.o drawing.o gtk.o malloc.o midend.o misc.o printing.o \ + ps.o random.o version.o + $(CC) $(XLDFLAGS) -o $@ blackbox.o drawing.o gtk.o malloc.o midend.o \ + misc.o printing.o ps.o random.o version.o + +bridges: bridges.o drawing.o dsf.o gtk.o malloc.o midend.o misc.o printing.o \ + ps.o random.o version.o + $(CC) $(XLDFLAGS) -o $@ bridges.o drawing.o dsf.o gtk.o malloc.o \ + midend.o misc.o printing.o ps.o random.o version.o + +cube: cube.o drawing.o gtk.o malloc.o midend.o misc.o printing.o ps.o \ + random.o version.o + $(CC) $(XLDFLAGS) -o $@ cube.o drawing.o gtk.o malloc.o midend.o \ + misc.o printing.o ps.o random.o version.o + +dominosa: dominosa.o drawing.o gtk.o malloc.o midend.o misc.o printing.o \ + ps.o random.o version.o + $(CC) $(XLDFLAGS) -o $@ dominosa.o drawing.o gtk.o malloc.o midend.o \ + misc.o printing.o ps.o random.o version.o + +fifteen: drawing.o fifteen.o gtk.o malloc.o midend.o misc.o printing.o ps.o \ + random.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o fifteen.o gtk.o malloc.o midend.o \ + misc.o printing.o ps.o random.o version.o + +flip: drawing.o flip.o gtk.o malloc.o midend.o misc.o printing.o ps.o \ + random.o tree234.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o flip.o gtk.o malloc.o midend.o \ + misc.o printing.o ps.o random.o tree234.o version.o + +guess: drawing.o gtk.o guess.o malloc.o midend.o misc.o printing.o ps.o \ + random.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o gtk.o guess.o malloc.o midend.o \ + misc.o printing.o ps.o random.o version.o + +inertia: drawing.o gtk.o inertia.o malloc.o midend.o misc.o printing.o ps.o \ + random.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o gtk.o inertia.o malloc.o midend.o \ + misc.o printing.o ps.o random.o version.o + +lightup: combi.o drawing.o gtk.o lightup.o malloc.o midend.o misc.o \ + printing.o ps.o random.o version.o + $(CC) $(XLDFLAGS) -o $@ combi.o drawing.o gtk.o lightup.o malloc.o \ + midend.o misc.o printing.o ps.o random.o version.o + +lightupsolver: combi.o lightup2.o malloc.o misc.o nullfe.o random.o + $(CC) $(ULDFLAGS) -o $@ combi.o lightup2.o malloc.o misc.o nullfe.o \ + random.o + +loopy: drawing.o dsf.o gtk.o loopy.o malloc.o midend.o misc.o printing.o \ + ps.o random.o tree234.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o dsf.o gtk.o loopy.o malloc.o \ + midend.o misc.o printing.o ps.o random.o tree234.o version.o \ + + +map: drawing.o dsf.o gtk.o malloc.o map.o midend.o misc.o printing.o ps.o \ + random.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o dsf.o gtk.o malloc.o map.o \ + midend.o misc.o printing.o ps.o random.o version.o + +mapsolver: dsf.o malloc.o map2.o misc.o nullfe.o random.o + $(CC) $(ULDFLAGS) -o $@ dsf.o malloc.o map2.o misc.o nullfe.o \ + random.o -lm + +mineobfusc: malloc.o mines2.o misc.o nullfe.o random.o tree234.o + $(CC) $(ULDFLAGS) -o $@ malloc.o mines2.o misc.o nullfe.o random.o \ + tree234.o + +mines: drawing.o gtk.o malloc.o midend.o mines.o misc.o printing.o ps.o \ + random.o tree234.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o gtk.o malloc.o midend.o mines.o \ + misc.o printing.o ps.o random.o tree234.o version.o + +net: drawing.o dsf.o gtk.o malloc.o midend.o misc.o net.o printing.o ps.o \ + random.o tree234.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o dsf.o gtk.o malloc.o midend.o \ + misc.o net.o printing.o ps.o random.o tree234.o version.o + +netslide: drawing.o gtk.o malloc.o midend.o misc.o netslide.o printing.o \ + ps.o random.o tree234.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o gtk.o malloc.o midend.o misc.o \ + netslide.o printing.o ps.o random.o tree234.o version.o + +nullgame: drawing.o gtk.o malloc.o midend.o misc.o nullgame.o printing.o \ + ps.o random.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o gtk.o malloc.o midend.o misc.o \ + nullgame.o printing.o ps.o random.o version.o + +pattern: drawing.o gtk.o malloc.o midend.o misc.o pattern.o printing.o ps.o \ + random.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o gtk.o malloc.o midend.o misc.o \ + pattern.o printing.o ps.o random.o version.o + +patternsolver: malloc.o misc.o nullfe.o pattern2.o random.o + $(CC) $(ULDFLAGS) -o $@ malloc.o misc.o nullfe.o pattern2.o random.o \ + + +pegs: drawing.o gtk.o malloc.o midend.o misc.o pegs.o printing.o ps.o \ + random.o tree234.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o gtk.o malloc.o midend.o misc.o \ + pegs.o printing.o ps.o random.o tree234.o version.o + +rect: drawing.o gtk.o malloc.o midend.o misc.o printing.o ps.o random.o \ + rect.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o gtk.o malloc.o midend.o misc.o \ + printing.o ps.o random.o rect.o version.o + +samegame: drawing.o gtk.o malloc.o midend.o misc.o printing.o ps.o random.o \ + samegame.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o gtk.o malloc.o midend.o misc.o \ + printing.o ps.o random.o samegame.o version.o + +sixteen: drawing.o gtk.o malloc.o midend.o misc.o printing.o ps.o random.o \ + sixteen.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o gtk.o malloc.o midend.o misc.o \ + printing.o ps.o random.o sixteen.o version.o + +slant: drawing.o dsf.o gtk.o malloc.o midend.o misc.o printing.o ps.o \ + random.o slant.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o dsf.o gtk.o malloc.o midend.o \ + misc.o printing.o ps.o random.o slant.o version.o + +slantsolver: dsf.o malloc.o misc.o nullfe.o random.o slant2.o + $(CC) $(ULDFLAGS) -o $@ dsf.o malloc.o misc.o nullfe.o random.o \ + slant2.o + +solo: drawing.o gtk.o malloc.o midend.o misc.o printing.o ps.o random.o \ + solo.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o gtk.o malloc.o midend.o misc.o \ + printing.o ps.o random.o solo.o version.o + +solosolver: malloc.o misc.o nullfe.o random.o solo2.o + $(CC) $(ULDFLAGS) -o $@ malloc.o misc.o nullfe.o random.o solo2.o + +tents: drawing.o gtk.o malloc.o maxflow.o midend.o misc.o printing.o ps.o \ + random.o tents.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o gtk.o malloc.o maxflow.o midend.o \ + misc.o printing.o ps.o random.o tents.o version.o + +tentssolver: malloc.o maxflow.o misc.o nullfe.o random.o tents2.o + $(CC) $(ULDFLAGS) -o $@ malloc.o maxflow.o misc.o nullfe.o random.o \ + tents2.o + +twiddle: drawing.o gtk.o malloc.o midend.o misc.o printing.o ps.o random.o \ + twiddle.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o gtk.o malloc.o midend.o misc.o \ + printing.o ps.o random.o twiddle.o version.o + +untangle: drawing.o gtk.o malloc.o midend.o misc.o printing.o ps.o random.o \ + tree234.o untangle.o version.o + $(CC) $(XLDFLAGS) -o $@ drawing.o gtk.o malloc.o midend.o misc.o \ + printing.o ps.o random.o tree234.o untangle.o version.o + +blackbox.o: ./blackbox.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +bridges.o: ./bridges.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +combi.o: ./combi.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +cube.o: ./cube.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +dominosa.o: ./dominosa.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +drawing.o: ./drawing.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +dsf.o: ./dsf.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +fifteen.o: ./fifteen.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +flip.o: ./flip.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +gtk.o: ./gtk.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +guess.o: ./guess.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +inertia.o: ./inertia.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +lightup.o: ./lightup.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +lightup2.o: ./lightup.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +list.o: ./list.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +loopy.o: ./loopy.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +malloc.o: ./malloc.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +map.o: ./map.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +map2.o: ./map.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +maxflow.o: ./maxflow.c ./maxflow.h ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +midend.o: ./midend.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +mines.o: ./mines.c ./tree234.h ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +mines2.o: ./mines.c ./tree234.h ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_OBFUSCATOR -c $< -o $@ +misc.o: ./misc.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +net.o: ./net.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +netslide.o: ./netslide.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +nullfe.o: ./nullfe.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +nullgame.o: ./nullgame.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +osx.o: ./osx.m ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +pattern.o: ./pattern.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +pattern2.o: ./pattern.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +pegs.o: ./pegs.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +printing.o: ./printing.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +ps.o: ./ps.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +random.o: ./random.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +rect.o: ./rect.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +samegame.o: ./samegame.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +sixteen.o: ./sixteen.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +slant.o: ./slant.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +slant2.o: ./slant.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +solo.o: ./solo.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +solo2.o: ./solo.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +tents.o: ./tents.c ./puzzles.h ./maxflow.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +tents2.o: ./tents.c ./puzzles.h ./maxflow.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +tree234.o: ./tree234.c ./tree234.h ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +twiddle.o: ./twiddle.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +untangle.o: ./untangle.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +windows.o: ./windows.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ + +version.o: FORCE; +FORCE: + if test -z "$(VER)" && test -f manifest && md5sum -c manifest; then \ + $(CC) $(COMPAT) $(XFLAGS) $(CFLAGS) `cat version.def` -c version.c; \ + elif test -z "$(VER)" && test -d .svn && svnversion . >&/dev/null; then \ + $(CC) $(COMPAT) $(XFLAGS) $(CFLAGS) "-DREVISION=`svnversion .`" -c version.c; \ + else \ + $(CC) $(COMPAT) $(XFLAGS) $(CFLAGS) $(VER) -c version.c; \ + fi +install: + for i in cube net netslide fifteen sixteen twiddle \ + pattern rect solo mines samegame flip guess \ + pegs dominosa untangle blackbox slant lightup \ + map loopy inertia tents bridges; do \ + $(INSTALL_PROGRAM) -m 755 $$i $(DESTDIR)$(gamesdir)/$$i \ + || exit 1; \ + done + +clean: + rm -f *.o blackbox bridges cube dominosa fifteen flip guess inertia lightup lightupsolver loopy map mapsolver mineobfusc mines net netslide nullgame pattern patternsolver pegs rect samegame sixteen slant slantsolver solo solosolver tents tentssolver twiddle untangle diff --git a/Makefile.cyg b/Makefile.cyg new file mode 100644 index 0000000..89e09c7 --- /dev/null +++ b/Makefile.cyg @@ -0,0 +1,335 @@ +# Makefile for puzzles under cygwin. +# +# This file was created by `mkfiles.pl' from the `Recipe' file. +# DO NOT EDIT THIS FILE DIRECTLY; edit Recipe or mkfiles.pl instead. + +# You can define this path to point at your tools if you need to +# TOOLPATH = c:\cygwin\bin\ # or similar, if you're running Windows +# TOOLPATH = /pkg/mingw32msvc/i386-mingw32msvc/bin/ +CC = $(TOOLPATH)gcc +RC = $(TOOLPATH)windres +# Uncomment the following two lines to compile under Winelib +# CC = winegcc +# RC = wrc +# You may also need to tell windres where to find include files: +# RCINC = --include-dir c:\cygwin\include\ + +CFLAGS = -mno-cygwin -Wall -O2 -D_WINDOWS -DDEBUG -DWIN32S_COMPAT \ + -D_NO_OLDNAMES -DNO_MULTIMON -I./ +LDFLAGS = -mno-cygwin -s +RCFLAGS = $(RCINC) --define WIN32=1 --define _WIN32=1 --define WINVER=0x0400 \ + --define MINGW32_FIX=1 + +all: blackbox.exe bridges.exe cube.exe dominosa.exe fifteen.exe flip.exe \ + guess.exe inertia.exe lightup.exe lightupsolver.exe \ + loopy.exe map.exe mapsolver.exe mineobfusc.exe mines.exe \ + netgame.exe netslide.exe nullgame.exe pattern.exe \ + patternsolver.exe pegs.exe rect.exe samegame.exe sixteen.exe \ + slant.exe slantsolver.exe solo.exe solosolver.exe tents.exe \ + tentssolver.exe twiddle.exe untangle.exe + +blackbox.exe: blackbox.o drawing.o malloc.o midend.o misc.o printing.o \ + random.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,blackbox.map blackbox.o \ + drawing.o malloc.o midend.o misc.o printing.o random.o \ + version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 \ + -lwinspool + +bridges.exe: bridges.o drawing.o dsf.o malloc.o midend.o misc.o printing.o \ + random.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,bridges.map bridges.o \ + drawing.o dsf.o malloc.o midend.o misc.o printing.o random.o \ + version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 \ + -lwinspool + +cube.exe: cube.o drawing.o malloc.o midend.o misc.o printing.o random.o \ + version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,cube.map cube.o drawing.o \ + malloc.o midend.o misc.o printing.o random.o version.o \ + windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 -lwinspool + +dominosa.exe: dominosa.o drawing.o malloc.o midend.o misc.o printing.o \ + random.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,dominosa.map dominosa.o \ + drawing.o malloc.o midend.o misc.o printing.o random.o \ + version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 \ + -lwinspool + +fifteen.exe: drawing.o fifteen.o malloc.o midend.o misc.o printing.o \ + random.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,fifteen.map drawing.o \ + fifteen.o malloc.o midend.o misc.o printing.o random.o \ + version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 \ + -lwinspool + +flip.exe: drawing.o flip.o malloc.o midend.o misc.o printing.o random.o \ + tree234.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,flip.map drawing.o flip.o \ + malloc.o midend.o misc.o printing.o random.o tree234.o \ + version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 \ + -lwinspool + +guess.exe: drawing.o guess.o malloc.o midend.o misc.o printing.o random.o \ + version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,guess.map drawing.o \ + guess.o malloc.o midend.o misc.o printing.o random.o \ + version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 \ + -lwinspool + +inertia.exe: drawing.o inertia.o malloc.o midend.o misc.o printing.o \ + random.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,inertia.map drawing.o \ + inertia.o malloc.o midend.o misc.o printing.o random.o \ + version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 \ + -lwinspool + +lightup.exe: combi.o drawing.o lightup.o malloc.o midend.o misc.o printing.o \ + random.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,lightup.map combi.o \ + drawing.o lightup.o malloc.o midend.o misc.o printing.o \ + random.o version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 \ + -luser32 -lwinspool + +lightupsolver.exe: combi.o lightup2.o malloc.o misc.o nullfe.o random.o + $(CC) $(LDFLAGS) -o $@ -Wl,-Map,lightupsolver.map combi.o lightup2.o \ + malloc.o misc.o nullfe.o random.o + +loopy.exe: drawing.o dsf.o loopy.o malloc.o midend.o misc.o printing.o \ + random.o tree234.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,loopy.map drawing.o dsf.o \ + loopy.o malloc.o midend.o misc.o printing.o random.o \ + tree234.o version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 \ + -luser32 -lwinspool + +map.exe: drawing.o dsf.o malloc.o map.o midend.o misc.o printing.o random.o \ + version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,map.map drawing.o dsf.o \ + malloc.o map.o midend.o misc.o printing.o random.o version.o \ + windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 -lwinspool + +mapsolver.exe: dsf.o malloc.o map2.o misc.o nullfe.o random.o + $(CC) $(LDFLAGS) -o $@ -Wl,-Map,mapsolver.map dsf.o malloc.o map2.o \ + misc.o nullfe.o random.o + +mineobfusc.exe: malloc.o mines2.o misc.o nullfe.o random.o tree234.o + $(CC) $(LDFLAGS) -o $@ -Wl,-Map,mineobfusc.map malloc.o mines2.o \ + misc.o nullfe.o random.o tree234.o + +mines.exe: drawing.o malloc.o midend.o mines.o misc.o printing.o random.o \ + tree234.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,mines.map drawing.o \ + malloc.o midend.o mines.o misc.o printing.o random.o \ + tree234.o version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 \ + -luser32 -lwinspool + +netgame.exe: drawing.o dsf.o malloc.o midend.o misc.o net.o printing.o \ + random.o tree234.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,netgame.map drawing.o \ + dsf.o malloc.o midend.o misc.o net.o printing.o random.o \ + tree234.o version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 \ + -luser32 -lwinspool + +netslide.exe: drawing.o malloc.o midend.o misc.o netslide.o printing.o \ + random.o tree234.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,netslide.map drawing.o \ + malloc.o midend.o misc.o netslide.o printing.o random.o \ + tree234.o version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 \ + -luser32 -lwinspool + +nullgame.exe: drawing.o malloc.o midend.o misc.o nullgame.o printing.o \ + random.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,nullgame.map drawing.o \ + malloc.o midend.o misc.o nullgame.o printing.o random.o \ + version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 \ + -lwinspool + +pattern.exe: drawing.o malloc.o midend.o misc.o pattern.o printing.o \ + random.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,pattern.map drawing.o \ + malloc.o midend.o misc.o pattern.o printing.o random.o \ + version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 \ + -lwinspool + +patternsolver.exe: malloc.o misc.o nullfe.o pattern2.o random.o + $(CC) $(LDFLAGS) -o $@ -Wl,-Map,patternsolver.map malloc.o misc.o \ + nullfe.o pattern2.o random.o + +pegs.exe: drawing.o malloc.o midend.o misc.o pegs.o printing.o random.o \ + tree234.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,pegs.map drawing.o \ + malloc.o midend.o misc.o pegs.o printing.o random.o \ + tree234.o version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 \ + -luser32 -lwinspool + +rect.exe: drawing.o malloc.o midend.o misc.o printing.o random.o rect.o \ + version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,rect.map drawing.o \ + malloc.o midend.o misc.o printing.o random.o rect.o \ + version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 \ + -lwinspool + +samegame.exe: drawing.o malloc.o midend.o misc.o printing.o random.o \ + samegame.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,samegame.map drawing.o \ + malloc.o midend.o misc.o printing.o random.o samegame.o \ + version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 \ + -lwinspool + +sixteen.exe: drawing.o malloc.o midend.o misc.o printing.o random.o \ + sixteen.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,sixteen.map drawing.o \ + malloc.o midend.o misc.o printing.o random.o sixteen.o \ + version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 \ + -lwinspool + +slant.exe: drawing.o dsf.o malloc.o midend.o misc.o printing.o random.o \ + slant.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,slant.map drawing.o dsf.o \ + malloc.o midend.o misc.o printing.o random.o slant.o \ + version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 \ + -lwinspool + +slantsolver.exe: dsf.o malloc.o misc.o nullfe.o random.o slant2.o + $(CC) $(LDFLAGS) -o $@ -Wl,-Map,slantsolver.map dsf.o malloc.o \ + misc.o nullfe.o random.o slant2.o + +solo.exe: drawing.o malloc.o midend.o misc.o printing.o random.o solo.o \ + version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,solo.map drawing.o \ + malloc.o midend.o misc.o printing.o random.o solo.o \ + version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 \ + -lwinspool + +solosolver.exe: malloc.o misc.o nullfe.o random.o solo2.o + $(CC) $(LDFLAGS) -o $@ -Wl,-Map,solosolver.map malloc.o misc.o \ + nullfe.o random.o solo2.o + +tents.exe: drawing.o malloc.o maxflow.o midend.o misc.o printing.o random.o \ + tents.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,tents.map drawing.o \ + malloc.o maxflow.o midend.o misc.o printing.o random.o \ + tents.o version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 \ + -luser32 -lwinspool + +tentssolver.exe: malloc.o maxflow.o misc.o nullfe.o random.o tents2.o + $(CC) $(LDFLAGS) -o $@ -Wl,-Map,tentssolver.map malloc.o maxflow.o \ + misc.o nullfe.o random.o tents2.o + +twiddle.exe: drawing.o malloc.o midend.o misc.o printing.o random.o \ + twiddle.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,twiddle.map drawing.o \ + malloc.o midend.o misc.o printing.o random.o twiddle.o \ + version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 -luser32 \ + -lwinspool + +untangle.exe: drawing.o malloc.o midend.o misc.o printing.o random.o \ + tree234.o untangle.o version.o windows.o + $(CC) -mwindows $(LDFLAGS) -o $@ -Wl,-Map,untangle.map drawing.o \ + malloc.o midend.o misc.o printing.o random.o tree234.o \ + untangle.o version.o windows.o -lcomctl32 -lcomdlg32 -lgdi32 \ + -luser32 -lwinspool + +blackbox.o: ./blackbox.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +bridges.o: ./bridges.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +combi.o: ./combi.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +cube.o: ./cube.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +dominosa.o: ./dominosa.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +drawing.o: ./drawing.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +dsf.o: ./dsf.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +fifteen.o: ./fifteen.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +flip.o: ./flip.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +gtk.o: ./gtk.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +guess.o: ./guess.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +inertia.o: ./inertia.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +lightup.o: ./lightup.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +lightup2.o: ./lightup.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +list.o: ./list.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +loopy.o: ./loopy.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +malloc.o: ./malloc.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +map.o: ./map.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +map2.o: ./map.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +maxflow.o: ./maxflow.c ./maxflow.h ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +midend.o: ./midend.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +mines.o: ./mines.c ./tree234.h ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +mines2.o: ./mines.c ./tree234.h ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_OBFUSCATOR -c $< -o $@ +misc.o: ./misc.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +net.o: ./net.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +netslide.o: ./netslide.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +nullfe.o: ./nullfe.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +nullgame.o: ./nullgame.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +osx.o: ./osx.m ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +pattern.o: ./pattern.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +pattern2.o: ./pattern.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +pegs.o: ./pegs.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +printing.o: ./printing.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +ps.o: ./ps.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +random.o: ./random.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +rect.o: ./rect.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +samegame.o: ./samegame.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +sixteen.o: ./sixteen.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +slant.o: ./slant.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +slant2.o: ./slant.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +solo.o: ./solo.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +solo2.o: ./solo.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +tents.o: ./tents.c ./puzzles.h ./maxflow.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +tents2.o: ./tents.c ./puzzles.h ./maxflow.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +tree234.o: ./tree234.c ./tree234.h ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +twiddle.o: ./twiddle.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +untangle.o: ./untangle.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +windows.o: ./windows.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ + +version.o: FORCE; +FORCE: + $(CC) $(COMPAT) $(XFLAGS) $(CFLAGS) $(VER) -c version.c + +clean: + rm -f *.o *.exe *.res.o *.map + diff --git a/Makefile.osx b/Makefile.osx new file mode 100644 index 0000000..d346a0a --- /dev/null +++ b/Makefile.osx @@ -0,0 +1,203 @@ +# Makefile for puzzles under Mac OS X. +# +# This file was created by `mkfiles.pl' from the `Recipe' file. +# DO NOT EDIT THIS FILE DIRECTLY; edit Recipe or mkfiles.pl instead. +CC = $(TOOLPATH)gcc + +CFLAGS = -O2 -Wall -Werror -g -I./ +LDFLAGS = -framework Cocoa +all: Puzzles lightupsolver mapsolver mineobfusc patternsolver slantsolver \ + solosolver tentssolver +CFLAGS += -DCOMBINED +Puzzles_extra = Puzzles.app/Contents/Resources/Help/index.html +Puzzles.app/Contents/Resources/Help/index.html: \ + Puzzles.app/Contents/Resources/Help osx-help.but puzzles.but + cd Puzzles.app/Contents/Resources/Help; \ + halibut --html ../../../../osx-help.but ../../../../puzzles.but +Puzzles.app/Contents/Resources/Help: Puzzles.app/Contents/Resources + mkdir -p Puzzles.app/Contents/Resources/Help + +release: Puzzles.dmg +Puzzles.dmg: Puzzles + rm -f raw.dmg + hdiutil create -megabytes 5 -layout NONE raw.dmg + hdid -nomount raw.dmg > devicename + newfs_hfs -v "Simon Tatham's Puzzle Collection" `cat devicename` + hdiutil eject `cat devicename` + hdid raw.dmg | cut -f1 -d' ' > devicename + cp -R Puzzles.app /Volumes/"Simon Tatham's Puzzle Collection" + hdiutil eject `cat devicename` + rm -f Puzzles.dmg + hdiutil convert -format UDCO raw.dmg -o Puzzles.dmg + rm -f raw.dmg devicename +version.o: FORCE; +FORCE: + if test -z "$(VER)" && test -f manifest && (md5 -r `awk '{print $$2}' manifest` | diff -w manifest -); then \ + $(CC) $(COMPAT) $(XFLAGS) $(CFLAGS) `cat version.def` -c version.c; \ + elif test -z "$(VER)" && test -d .svn && svnversion . >&/dev/null; then \ + $(CC) $(COMPAT) $(XFLAGS) $(CFLAGS) "-DREVISION=`svnversion .`" -c version.c; \ + else \ + $(CC) $(COMPAT) $(XFLAGS) $(CFLAGS) $(VER) -c version.c; \ + fi + +.SUFFIXES: .o .c .m + + + +Puzzles.app: + mkdir -p $@ +Puzzles.app/Contents: Puzzles.app + mkdir -p $@ +Puzzles.app/Contents/MacOS: Puzzles.app/Contents + mkdir -p $@ +Puzzles.app/Contents/Resources: Puzzles.app/Contents + mkdir -p $@ +Puzzles.app/Contents/Resources/Puzzles.icns: Puzzles.app/Contents/Resources osx.icns + cp osx.icns $@ +Puzzles.app/Contents/Info.plist: Puzzles.app/Contents/Resources osx-info.plist + cp osx-info.plist $@ +Puzzles: Puzzles.app/Contents/MacOS/Puzzles \ + Puzzles.app/Contents/Resources/Puzzles.icns \ + Puzzles.app/Contents/Info.plist $(Puzzles_extra) + +Puzzles.app/Contents/MacOS/Puzzles: Puzzles.app/Contents/MacOS blackbox.o \ + bridges.o combi.o cube.o dominosa.o drawing.o dsf.o \ + fifteen.o flip.o guess.o inertia.o lightup.o list.o loopy.o \ + malloc.o map.o maxflow.o midend.o mines.o misc.o net.o \ + netslide.o osx.o pattern.o pegs.o random.o rect.o samegame.o \ + sixteen.o slant.o solo.o tents.o tree234.o twiddle.o \ + untangle.o version.o + $(CC) $(LDFLAGS) -o $@ blackbox.o bridges.o combi.o cube.o \ + dominosa.o drawing.o dsf.o fifteen.o flip.o guess.o \ + inertia.o lightup.o list.o loopy.o malloc.o map.o maxflow.o \ + midend.o mines.o misc.o net.o netslide.o osx.o pattern.o \ + pegs.o random.o rect.o samegame.o sixteen.o slant.o solo.o \ + tents.o tree234.o twiddle.o untangle.o version.o + +lightupsolver: combi.o lightup2.o malloc.o misc.o nullfe.o random.o + $(CC) $(ULDFLAGS) -o $@ combi.o lightup2.o malloc.o misc.o nullfe.o \ + random.o + +mapsolver: dsf.o malloc.o map2.o misc.o nullfe.o random.o + $(CC) $(ULDFLAGS) -o $@ dsf.o malloc.o map2.o misc.o nullfe.o \ + random.o -lm + +mineobfusc: malloc.o mines2.o misc.o nullfe.o random.o tree234.o + $(CC) $(ULDFLAGS) -o $@ malloc.o mines2.o misc.o nullfe.o random.o \ + tree234.o + +patternsolver: malloc.o misc.o nullfe.o pattern2.o random.o + $(CC) $(ULDFLAGS) -o $@ malloc.o misc.o nullfe.o pattern2.o random.o \ + + +slantsolver: dsf.o malloc.o misc.o nullfe.o random.o slant2.o + $(CC) $(ULDFLAGS) -o $@ dsf.o malloc.o misc.o nullfe.o random.o \ + slant2.o + +solosolver: malloc.o misc.o nullfe.o random.o solo2.o + $(CC) $(ULDFLAGS) -o $@ malloc.o misc.o nullfe.o random.o solo2.o + +tentssolver: malloc.o maxflow.o misc.o nullfe.o random.o tents2.o + $(CC) $(ULDFLAGS) -o $@ malloc.o maxflow.o misc.o nullfe.o random.o \ + tents2.o + +blackbox.o: ./blackbox.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +bridges.o: ./bridges.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +combi.o: ./combi.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +cube.o: ./cube.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +dominosa.o: ./dominosa.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +drawing.o: ./drawing.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +dsf.o: ./dsf.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +fifteen.o: ./fifteen.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +flip.o: ./flip.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +gtk.o: ./gtk.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +guess.o: ./guess.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +inertia.o: ./inertia.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +lightup.o: ./lightup.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +lightup2.o: ./lightup.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +list.o: ./list.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +loopy.o: ./loopy.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +malloc.o: ./malloc.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +map.o: ./map.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +map2.o: ./map.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +maxflow.o: ./maxflow.c ./maxflow.h ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +midend.o: ./midend.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +mines.o: ./mines.c ./tree234.h ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +mines2.o: ./mines.c ./tree234.h ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_OBFUSCATOR -c $< -o $@ +misc.o: ./misc.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +net.o: ./net.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +netslide.o: ./netslide.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +nullfe.o: ./nullfe.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +nullgame.o: ./nullgame.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +osx.o: ./osx.m ./puzzles.h + $(CC) -x objective-c $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +pattern.o: ./pattern.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +pattern2.o: ./pattern.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +pegs.o: ./pegs.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +printing.o: ./printing.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +ps.o: ./ps.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +random.o: ./random.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +rect.o: ./rect.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +samegame.o: ./samegame.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +sixteen.o: ./sixteen.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +slant.o: ./slant.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +slant2.o: ./slant.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +solo.o: ./solo.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +solo2.o: ./solo.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +tents.o: ./tents.c ./puzzles.h ./maxflow.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +tents2.o: ./tents.c ./puzzles.h ./maxflow.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -DSTANDALONE_SOLVER -c $< -o $@ +tree234.o: ./tree234.c ./tree234.h ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +twiddle.o: ./twiddle.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +untangle.o: ./untangle.c ./puzzles.h ./tree234.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ +windows.o: ./windows.c ./puzzles.h + $(CC) $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) -c $< -o $@ + +clean: + rm -f *.o *.dmg lightupsolver mapsolver mineobfusc patternsolver slantsolver solosolver tentssolver + rm -rf *.app diff --git a/Makefile.vc b/Makefile.vc new file mode 100644 index 0000000..feda3db --- /dev/null +++ b/Makefile.vc @@ -0,0 +1,484 @@ +# Makefile for puzzles under Visual C. +# +# This file was created by `mkfiles.pl' from the `Recipe' file. +# DO NOT EDIT THIS FILE DIRECTLY; edit Recipe or mkfiles.pl instead. + +# If you rename this file to `Makefile', you should change this line, +# so that the .rsp files still depend on the correct makefile. +MAKEFILE = Makefile.vc + +# C compilation flags +CFLAGS = /nologo /W3 /O1 /D_WINDOWS /D_WIN32_WINDOWS=0x401 /DWINVER=0x401 +LFLAGS = /incremental:no /fixed + +all: blackbox.exe bridges.exe cube.exe dominosa.exe fifteen.exe flip.exe \ + guess.exe inertia.exe lightup.exe lightupsolver.exe \ + loopy.exe map.exe mapsolver.exe mineobfusc.exe mines.exe \ + netgame.exe netslide.exe nullgame.exe pattern.exe \ + patternsolver.exe pegs.exe rect.exe samegame.exe sixteen.exe \ + slant.exe slantsolver.exe solo.exe solosolver.exe tents.exe \ + tentssolver.exe twiddle.exe untangle.exe + +blackbox.exe: blackbox.obj drawing.obj malloc.obj midend.obj misc.obj \ + printing.obj random.obj version.obj windows.obj blackbox.rsp + link $(LFLAGS) -out:blackbox.exe -map:blackbox.map @blackbox.rsp + +bridges.exe: bridges.obj drawing.obj dsf.obj malloc.obj midend.obj misc.obj \ + printing.obj random.obj version.obj windows.obj bridges.rsp + link $(LFLAGS) -out:bridges.exe -map:bridges.map @bridges.rsp + +cube.exe: cube.obj drawing.obj malloc.obj midend.obj misc.obj printing.obj \ + random.obj version.obj windows.obj cube.rsp + link $(LFLAGS) -out:cube.exe -map:cube.map @cube.rsp + +dominosa.exe: dominosa.obj drawing.obj malloc.obj midend.obj misc.obj \ + printing.obj random.obj version.obj windows.obj dominosa.rsp + link $(LFLAGS) -out:dominosa.exe -map:dominosa.map @dominosa.rsp + +fifteen.exe: drawing.obj fifteen.obj malloc.obj midend.obj misc.obj \ + printing.obj random.obj version.obj windows.obj fifteen.rsp + link $(LFLAGS) -out:fifteen.exe -map:fifteen.map @fifteen.rsp + +flip.exe: drawing.obj flip.obj malloc.obj midend.obj misc.obj printing.obj \ + random.obj tree234.obj version.obj windows.obj flip.rsp + link $(LFLAGS) -out:flip.exe -map:flip.map @flip.rsp + +guess.exe: drawing.obj guess.obj malloc.obj midend.obj misc.obj printing.obj \ + random.obj version.obj windows.obj guess.rsp + link $(LFLAGS) -out:guess.exe -map:guess.map @guess.rsp + +inertia.exe: drawing.obj inertia.obj malloc.obj midend.obj misc.obj \ + printing.obj random.obj version.obj windows.obj inertia.rsp + link $(LFLAGS) -out:inertia.exe -map:inertia.map @inertia.rsp + +lightup.exe: combi.obj drawing.obj lightup.obj malloc.obj midend.obj \ + misc.obj printing.obj random.obj version.obj windows.obj \ + lightup.rsp + link $(LFLAGS) -out:lightup.exe -map:lightup.map @lightup.rsp + +lightupsolver.exe: combi.obj lightup2.obj malloc.obj misc.obj nullfe.obj \ + random.obj lightupsolver.rsp + link $(LFLAGS) -out:lightupsolver.exe -map:lightupsolver.map @lightupsolver.rsp + +loopy.exe: drawing.obj dsf.obj loopy.obj malloc.obj midend.obj misc.obj \ + printing.obj random.obj tree234.obj version.obj windows.obj \ + loopy.rsp + link $(LFLAGS) -out:loopy.exe -map:loopy.map @loopy.rsp + +map.exe: drawing.obj dsf.obj malloc.obj map.obj midend.obj misc.obj \ + printing.obj random.obj version.obj windows.obj map.rsp + link $(LFLAGS) -out:map.exe -map:map.map @map.rsp + +mapsolver.exe: dsf.obj malloc.obj map2.obj misc.obj nullfe.obj random.obj \ + mapsolver.rsp + link $(LFLAGS) -out:mapsolver.exe -map:mapsolver.map @mapsolver.rsp + +mineobfusc.exe: malloc.obj mines2.obj misc.obj nullfe.obj random.obj \ + tree234.obj mineobfusc.rsp + link $(LFLAGS) -out:mineobfusc.exe -map:mineobfusc.map @mineobfusc.rsp + +mines.exe: drawing.obj malloc.obj midend.obj mines.obj misc.obj printing.obj \ + random.obj tree234.obj version.obj windows.obj mines.rsp + link $(LFLAGS) -out:mines.exe -map:mines.map @mines.rsp + +netgame.exe: drawing.obj dsf.obj malloc.obj midend.obj misc.obj net.obj \ + printing.obj random.obj tree234.obj version.obj windows.obj \ + netgame.rsp + link $(LFLAGS) -out:netgame.exe -map:netgame.map @netgame.rsp + +netslide.exe: drawing.obj malloc.obj midend.obj misc.obj netslide.obj \ + printing.obj random.obj tree234.obj version.obj windows.obj \ + netslide.rsp + link $(LFLAGS) -out:netslide.exe -map:netslide.map @netslide.rsp + +nullgame.exe: drawing.obj malloc.obj midend.obj misc.obj nullgame.obj \ + printing.obj random.obj version.obj windows.obj nullgame.rsp + link $(LFLAGS) -out:nullgame.exe -map:nullgame.map @nullgame.rsp + +pattern.exe: drawing.obj malloc.obj midend.obj misc.obj pattern.obj \ + printing.obj random.obj version.obj windows.obj pattern.rsp + link $(LFLAGS) -out:pattern.exe -map:pattern.map @pattern.rsp + +patternsolver.exe: malloc.obj misc.obj nullfe.obj pattern2.obj random.obj \ + patternsolver.rsp + link $(LFLAGS) -out:patternsolver.exe -map:patternsolver.map @patternsolver.rsp + +pegs.exe: drawing.obj malloc.obj midend.obj misc.obj pegs.obj printing.obj \ + random.obj tree234.obj version.obj windows.obj pegs.rsp + link $(LFLAGS) -out:pegs.exe -map:pegs.map @pegs.rsp + +rect.exe: drawing.obj malloc.obj midend.obj misc.obj printing.obj random.obj \ + rect.obj version.obj windows.obj rect.rsp + link $(LFLAGS) -out:rect.exe -map:rect.map @rect.rsp + +samegame.exe: drawing.obj malloc.obj midend.obj misc.obj printing.obj \ + random.obj samegame.obj version.obj windows.obj samegame.rsp + link $(LFLAGS) -out:samegame.exe -map:samegame.map @samegame.rsp + +sixteen.exe: drawing.obj malloc.obj midend.obj misc.obj printing.obj \ + random.obj sixteen.obj version.obj windows.obj sixteen.rsp + link $(LFLAGS) -out:sixteen.exe -map:sixteen.map @sixteen.rsp + +slant.exe: drawing.obj dsf.obj malloc.obj midend.obj misc.obj printing.obj \ + random.obj slant.obj version.obj windows.obj slant.rsp + link $(LFLAGS) -out:slant.exe -map:slant.map @slant.rsp + +slantsolver.exe: dsf.obj malloc.obj misc.obj nullfe.obj random.obj \ + slant2.obj slantsolver.rsp + link $(LFLAGS) -out:slantsolver.exe -map:slantsolver.map @slantsolver.rsp + +solo.exe: drawing.obj malloc.obj midend.obj misc.obj printing.obj random.obj \ + solo.obj version.obj windows.obj solo.rsp + link $(LFLAGS) -out:solo.exe -map:solo.map @solo.rsp + +solosolver.exe: malloc.obj misc.obj nullfe.obj random.obj solo2.obj \ + solosolver.rsp + link $(LFLAGS) -out:solosolver.exe -map:solosolver.map @solosolver.rsp + +tents.exe: drawing.obj malloc.obj maxflow.obj midend.obj misc.obj \ + printing.obj random.obj tents.obj version.obj windows.obj \ + tents.rsp + link $(LFLAGS) -out:tents.exe -map:tents.map @tents.rsp + +tentssolver.exe: malloc.obj maxflow.obj misc.obj nullfe.obj random.obj \ + tents2.obj tentssolver.rsp + link $(LFLAGS) -out:tentssolver.exe -map:tentssolver.map @tentssolver.rsp + +twiddle.exe: drawing.obj malloc.obj midend.obj misc.obj printing.obj \ + random.obj twiddle.obj version.obj windows.obj twiddle.rsp + link $(LFLAGS) -out:twiddle.exe -map:twiddle.map @twiddle.rsp + +untangle.exe: drawing.obj malloc.obj midend.obj misc.obj printing.obj \ + random.obj tree234.obj untangle.obj version.obj windows.obj \ + untangle.rsp + link $(LFLAGS) -out:untangle.exe -map:untangle.map @untangle.rsp + +blackbox.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > blackbox.rsp + echo blackbox.obj comctl32.lib comdlg32.lib >> blackbox.rsp + echo drawing.obj gdi32.lib malloc.obj midend.obj >> blackbox.rsp + echo misc.obj printing.obj random.obj user32.lib >> blackbox.rsp + echo version.obj windows.obj winspool.lib >> blackbox.rsp + +bridges.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > bridges.rsp + echo bridges.obj comctl32.lib comdlg32.lib drawing.obj >> bridges.rsp + echo dsf.obj gdi32.lib malloc.obj midend.obj misc.obj >> bridges.rsp + echo printing.obj random.obj user32.lib version.obj >> bridges.rsp + echo windows.obj winspool.lib >> bridges.rsp + +cube.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > cube.rsp + echo comctl32.lib comdlg32.lib cube.obj drawing.obj >> cube.rsp + echo gdi32.lib malloc.obj midend.obj misc.obj >> cube.rsp + echo printing.obj random.obj user32.lib version.obj >> cube.rsp + echo windows.obj winspool.lib >> cube.rsp + +dominosa.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > dominosa.rsp + echo comctl32.lib comdlg32.lib dominosa.obj >> dominosa.rsp + echo drawing.obj gdi32.lib malloc.obj midend.obj >> dominosa.rsp + echo misc.obj printing.obj random.obj user32.lib >> dominosa.rsp + echo version.obj windows.obj winspool.lib >> dominosa.rsp + +fifteen.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > fifteen.rsp + echo comctl32.lib comdlg32.lib drawing.obj fifteen.obj >> fifteen.rsp + echo gdi32.lib malloc.obj midend.obj misc.obj >> fifteen.rsp + echo printing.obj random.obj user32.lib version.obj >> fifteen.rsp + echo windows.obj winspool.lib >> fifteen.rsp + +flip.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > flip.rsp + echo comctl32.lib comdlg32.lib drawing.obj flip.obj >> flip.rsp + echo gdi32.lib malloc.obj midend.obj misc.obj >> flip.rsp + echo printing.obj random.obj tree234.obj user32.lib >> flip.rsp + echo version.obj windows.obj winspool.lib >> flip.rsp + +guess.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > guess.rsp + echo comctl32.lib comdlg32.lib drawing.obj gdi32.lib >> guess.rsp + echo guess.obj malloc.obj midend.obj misc.obj >> guess.rsp + echo printing.obj random.obj user32.lib version.obj >> guess.rsp + echo windows.obj winspool.lib >> guess.rsp + +inertia.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > inertia.rsp + echo comctl32.lib comdlg32.lib drawing.obj gdi32.lib >> inertia.rsp + echo inertia.obj malloc.obj midend.obj misc.obj >> inertia.rsp + echo printing.obj random.obj user32.lib version.obj >> inertia.rsp + echo windows.obj winspool.lib >> inertia.rsp + +lightup.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > lightup.rsp + echo combi.obj comctl32.lib comdlg32.lib drawing.obj >> lightup.rsp + echo gdi32.lib lightup.obj malloc.obj midend.obj >> lightup.rsp + echo misc.obj printing.obj random.obj user32.lib >> lightup.rsp + echo version.obj windows.obj winspool.lib >> lightup.rsp + +lightupsolver.rsp: $(MAKEFILE) + echo /nologo /subsystem:console > lightupsolver.rsp + echo combi.obj lightup2.obj malloc.obj misc.obj >> lightupsolver.rsp + echo nullfe.obj random.obj >> lightupsolver.rsp + +loopy.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > loopy.rsp + echo comctl32.lib comdlg32.lib drawing.obj dsf.obj >> loopy.rsp + echo gdi32.lib loopy.obj malloc.obj midend.obj >> loopy.rsp + echo misc.obj printing.obj random.obj tree234.obj >> loopy.rsp + echo user32.lib version.obj windows.obj winspool.lib >> loopy.rsp + +map.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > map.rsp + echo comctl32.lib comdlg32.lib drawing.obj dsf.obj >> map.rsp + echo gdi32.lib malloc.obj map.obj midend.obj misc.obj >> map.rsp + echo printing.obj random.obj user32.lib version.obj >> map.rsp + echo windows.obj winspool.lib >> map.rsp + +mapsolver.rsp: $(MAKEFILE) + echo /nologo /subsystem:console > mapsolver.rsp + echo dsf.obj malloc.obj map2.obj misc.obj nullfe.obj >> mapsolver.rsp + echo random.obj >> mapsolver.rsp + +mineobfusc.rsp: $(MAKEFILE) + echo /nologo /subsystem:console > mineobfusc.rsp + echo malloc.obj mines2.obj misc.obj nullfe.obj >> mineobfusc.rsp + echo random.obj tree234.obj >> mineobfusc.rsp + +mines.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > mines.rsp + echo comctl32.lib comdlg32.lib drawing.obj gdi32.lib >> mines.rsp + echo malloc.obj midend.obj mines.obj misc.obj >> mines.rsp + echo printing.obj random.obj tree234.obj user32.lib >> mines.rsp + echo version.obj windows.obj winspool.lib >> mines.rsp + +netgame.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > netgame.rsp + echo comctl32.lib comdlg32.lib drawing.obj dsf.obj >> netgame.rsp + echo gdi32.lib malloc.obj midend.obj misc.obj net.obj >> netgame.rsp + echo printing.obj random.obj tree234.obj user32.lib >> netgame.rsp + echo version.obj windows.obj winspool.lib >> netgame.rsp + +netslide.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > netslide.rsp + echo comctl32.lib comdlg32.lib drawing.obj gdi32.lib >> netslide.rsp + echo malloc.obj midend.obj misc.obj netslide.obj >> netslide.rsp + echo printing.obj random.obj tree234.obj user32.lib >> netslide.rsp + echo version.obj windows.obj winspool.lib >> netslide.rsp + +nullgame.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > nullgame.rsp + echo comctl32.lib comdlg32.lib drawing.obj gdi32.lib >> nullgame.rsp + echo malloc.obj midend.obj misc.obj nullgame.obj >> nullgame.rsp + echo printing.obj random.obj user32.lib version.obj >> nullgame.rsp + echo windows.obj winspool.lib >> nullgame.rsp + +pattern.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > pattern.rsp + echo comctl32.lib comdlg32.lib drawing.obj gdi32.lib >> pattern.rsp + echo malloc.obj midend.obj misc.obj pattern.obj >> pattern.rsp + echo printing.obj random.obj user32.lib version.obj >> pattern.rsp + echo windows.obj winspool.lib >> pattern.rsp + +patternsolver.rsp: $(MAKEFILE) + echo /nologo /subsystem:console > patternsolver.rsp + echo malloc.obj misc.obj nullfe.obj pattern2.obj >> patternsolver.rsp + echo random.obj >> patternsolver.rsp + +pegs.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > pegs.rsp + echo comctl32.lib comdlg32.lib drawing.obj gdi32.lib >> pegs.rsp + echo malloc.obj midend.obj misc.obj pegs.obj >> pegs.rsp + echo printing.obj random.obj tree234.obj user32.lib >> pegs.rsp + echo version.obj windows.obj winspool.lib >> pegs.rsp + +rect.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > rect.rsp + echo comctl32.lib comdlg32.lib drawing.obj gdi32.lib >> rect.rsp + echo malloc.obj midend.obj misc.obj printing.obj >> rect.rsp + echo random.obj rect.obj user32.lib version.obj >> rect.rsp + echo windows.obj winspool.lib >> rect.rsp + +samegame.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > samegame.rsp + echo comctl32.lib comdlg32.lib drawing.obj gdi32.lib >> samegame.rsp + echo malloc.obj midend.obj misc.obj printing.obj >> samegame.rsp + echo random.obj samegame.obj user32.lib version.obj >> samegame.rsp + echo windows.obj winspool.lib >> samegame.rsp + +sixteen.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > sixteen.rsp + echo comctl32.lib comdlg32.lib drawing.obj gdi32.lib >> sixteen.rsp + echo malloc.obj midend.obj misc.obj printing.obj >> sixteen.rsp + echo random.obj sixteen.obj user32.lib version.obj >> sixteen.rsp + echo windows.obj winspool.lib >> sixteen.rsp + +slant.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > slant.rsp + echo comctl32.lib comdlg32.lib drawing.obj dsf.obj >> slant.rsp + echo gdi32.lib malloc.obj midend.obj misc.obj >> slant.rsp + echo printing.obj random.obj slant.obj user32.lib >> slant.rsp + echo version.obj windows.obj winspool.lib >> slant.rsp + +slantsolver.rsp: $(MAKEFILE) + echo /nologo /subsystem:console > slantsolver.rsp + echo dsf.obj malloc.obj misc.obj nullfe.obj random.obj >> slantsolver.rsp + echo slant2.obj >> slantsolver.rsp + +solo.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > solo.rsp + echo comctl32.lib comdlg32.lib drawing.obj gdi32.lib >> solo.rsp + echo malloc.obj midend.obj misc.obj printing.obj >> solo.rsp + echo random.obj solo.obj user32.lib version.obj >> solo.rsp + echo windows.obj winspool.lib >> solo.rsp + +solosolver.rsp: $(MAKEFILE) + echo /nologo /subsystem:console > solosolver.rsp + echo malloc.obj misc.obj nullfe.obj random.obj >> solosolver.rsp + echo solo2.obj >> solosolver.rsp + +tents.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > tents.rsp + echo comctl32.lib comdlg32.lib drawing.obj gdi32.lib >> tents.rsp + echo malloc.obj maxflow.obj midend.obj misc.obj >> tents.rsp + echo printing.obj random.obj tents.obj user32.lib >> tents.rsp + echo version.obj windows.obj winspool.lib >> tents.rsp + +tentssolver.rsp: $(MAKEFILE) + echo /nologo /subsystem:console > tentssolver.rsp + echo malloc.obj maxflow.obj misc.obj nullfe.obj >> tentssolver.rsp + echo random.obj tents2.obj >> tentssolver.rsp + +twiddle.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > twiddle.rsp + echo comctl32.lib comdlg32.lib drawing.obj gdi32.lib >> twiddle.rsp + echo malloc.obj midend.obj misc.obj printing.obj >> twiddle.rsp + echo random.obj twiddle.obj user32.lib version.obj >> twiddle.rsp + echo windows.obj winspool.lib >> twiddle.rsp + +untangle.rsp: $(MAKEFILE) + echo /nologo /subsystem:windows > untangle.rsp + echo comctl32.lib comdlg32.lib drawing.obj gdi32.lib >> untangle.rsp + echo malloc.obj midend.obj misc.obj printing.obj >> untangle.rsp + echo random.obj tree234.obj untangle.obj user32.lib >> untangle.rsp + echo version.obj windows.obj winspool.lib >> untangle.rsp + +blackbox.obj: .\blackbox.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\blackbox.c /Foblackbox.obj +bridges.obj: .\bridges.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\bridges.c /Fobridges.obj +combi.obj: .\combi.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\combi.c /Focombi.obj +cube.obj: .\cube.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\cube.c /Focube.obj +dominosa.obj: .\dominosa.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\dominosa.c /Fodominosa.obj +drawing.obj: .\drawing.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\drawing.c /Fodrawing.obj +dsf.obj: .\dsf.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\dsf.c /Fodsf.obj +fifteen.obj: .\fifteen.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\fifteen.c /Fofifteen.obj +flip.obj: .\flip.c .\puzzles.h .\tree234.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\flip.c /Foflip.obj +gtk.obj: .\gtk.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\gtk.c /Fogtk.obj +guess.obj: .\guess.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\guess.c /Foguess.obj +inertia.obj: .\inertia.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\inertia.c /Foinertia.obj +lightup.obj: .\lightup.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\lightup.c /Folightup.obj +lightup2.obj: .\lightup.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /DSTANDALONE_SOLVER /c .\lightup.c /Folightup2.obj +list.obj: .\list.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\list.c /Folist.obj +loopy.obj: .\loopy.c .\puzzles.h .\tree234.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\loopy.c /Foloopy.obj +malloc.obj: .\malloc.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\malloc.c /Fomalloc.obj +map.obj: .\map.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\map.c /Fomap.obj +map2.obj: .\map.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /DSTANDALONE_SOLVER /c .\map.c /Fomap2.obj +maxflow.obj: .\maxflow.c .\maxflow.h .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\maxflow.c /Fomaxflow.obj +midend.obj: .\midend.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\midend.c /Fomidend.obj +mines.obj: .\mines.c .\tree234.h .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\mines.c /Fomines.obj +mines2.obj: .\mines.c .\tree234.h .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /DSTANDALONE_OBFUSCATOR /c .\mines.c /Fomines2.obj +misc.obj: .\misc.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\misc.c /Fomisc.obj +net.obj: .\net.c .\puzzles.h .\tree234.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\net.c /Fonet.obj +netslide.obj: .\netslide.c .\puzzles.h .\tree234.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\netslide.c /Fonetslide.obj +nullfe.obj: .\nullfe.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\nullfe.c /Fonullfe.obj +nullgame.obj: .\nullgame.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\nullgame.c /Fonullgame.obj +osx.obj: .\osx.m .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\osx.m /Foosx.obj +pattern.obj: .\pattern.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\pattern.c /Fopattern.obj +pattern2.obj: .\pattern.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /DSTANDALONE_SOLVER /c .\pattern.c /Fopattern2.obj +pegs.obj: .\pegs.c .\puzzles.h .\tree234.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\pegs.c /Fopegs.obj +printing.obj: .\printing.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\printing.c /Foprinting.obj +ps.obj: .\ps.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\ps.c /Fops.obj +random.obj: .\random.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\random.c /Forandom.obj +rect.obj: .\rect.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\rect.c /Forect.obj +samegame.obj: .\samegame.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\samegame.c /Fosamegame.obj +sixteen.obj: .\sixteen.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\sixteen.c /Fosixteen.obj +slant.obj: .\slant.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\slant.c /Foslant.obj +slant2.obj: .\slant.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /DSTANDALONE_SOLVER /c .\slant.c /Foslant2.obj +solo.obj: .\solo.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\solo.c /Fosolo.obj +solo2.obj: .\solo.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /DSTANDALONE_SOLVER /c .\solo.c /Fosolo2.obj +tents.obj: .\tents.c .\puzzles.h .\maxflow.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\tents.c /Fotents.obj +tents2.obj: .\tents.c .\puzzles.h .\maxflow.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /DSTANDALONE_SOLVER /c .\tents.c /Fotents2.obj +tree234.obj: .\tree234.c .\tree234.h .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\tree234.c /Fotree234.obj +twiddle.obj: .\twiddle.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\twiddle.c /Fotwiddle.obj +untangle.obj: .\untangle.c .\puzzles.h .\tree234.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\untangle.c /Fountangle.obj +windows.obj: .\windows.c .\puzzles.h + cl $(COMPAT) $(FWHACK) $(CFLAGS) $(XFLAGS) /c .\windows.c /Fowindows.obj + +version.obj: *.c *.h + cl $(VER) $(CFLAGS) /c version.c + +clean: tidy + -del *.exe + +tidy: + -del *.obj + -del *.res + -del *.pch + -del *.aps + -del *.ilk + -del *.pdb + -del *.rsp + -del *.dsp + -del *.dsw + -del *.ncb + -del *.opt + -del *.plg + -del *.map + -del *.idb + -del debug.log diff --git a/makedist.sh b/makedist.sh deleted file mode 100755 index bc29595..0000000 --- a/makedist.sh +++ /dev/null @@ -1,57 +0,0 @@ -#!/bin/sh - -# Build a Unix source distribution from the Puzzles SVN area. -# -# Pass a numeric argument to have the archive tagged as that SVN -# revision. Otherwise, the script will work it out itself by -# calling `svnversion', or failing that it will not version-tag the -# archive at all. - -case "$#" in - 0) - # Ignore errors; if we can't get a version, we'll have a blank - # string. - rev=`svnversion . 2>/dev/null` - if test "x$rev" = "xexported"; then rev=; fi - ;; - *) - case "$1" in *[!0-9]*) echo "Malformed revision number '$1'">&2;exit 1;;esac - rev="$1" - ;; -esac - -if test "x$rev" != "x"; then - arcsuffix="-r$rev" - ver="-DREVISION=$rev" -else - arcsuffix= - ver= -fi - -perl mkfiles.pl - -mkdir tmp.$$ -mkdir tmp.$$/puzzles$arcsuffix - -# Build Windows Help and text versions of the manual for convenience. -halibut --winhelp=puzzles.hlp --text=puzzles.txt puzzles.but - -# Build a text version of the HACKING document. -halibut --text=HACKING devel.but - -for i in *.c *.m *.h *.but *.plist *.icns LICENCE README Recipe \ - mkfiles.pl Makefile Makefile.* \ - HACKING puzzles.txt puzzles.hlp puzzles.cnt; do - ln -s ../../$i tmp.$$/puzzles$arcsuffix - if test "x$ver" != "x"; then - md5sum $i >> tmp.$$/puzzles$arcsuffix/manifest - fi -done - -if test "x$ver" != "x"; then - echo "$ver" >> tmp.$$/puzzles$arcsuffix/version.def -fi - -tar -C tmp.$$ -chzf - puzzles$arcsuffix > ../puzzles$arcsuffix.tar.gz - -rm -rf tmp.$$ diff --git a/manifest b/manifest new file mode 100644 index 0000000..91d5792 --- /dev/null +++ b/manifest @@ -0,0 +1,63 @@ +b95260f8a875a9eae293baa80676a14c blackbox.c +f68cd741a88b9e16957945ce7d3e0dc6 bridges.c +bf43b3ca986831f66815bd850a8e139f combi.c +e70b81328ca8b6733aba9585781b66ea cube.c +ffd524bf08fc5fb05b18b22466da78a3 dominosa.c +994c5ccf11512e398e0cf1ed17e9f55c drawing.c +c5351b0d3edc4936eae2893052f7d9e1 dsf.c +a45f844a8eaad38803103ffc996de6bc fifteen.c +de8984bc2c20ba7a1ce6165b31186081 flip.c +a7be34921ef761ccac6feacd5c8cbedc gtk.c +1fa0d0ef322d2572103364f7f84a7e17 guess.c +5ad6b860dca9a0ed9782cb93fcc99763 inertia.c +1ddf0f436786b3da1d0ae4fdc02bef98 lightup.c +3cb2bc5d8ddd5a1962dc01ce30936762 list.c +c27e61ad85bf7bee8c0a7d8e2ae1c8eb loopy.c +6e377a27462e3f457168386b94ed3c87 malloc.c +49cb842b5de2245a1daae87d13f7fd2d map.c +76188048008e3cf8edea94543aad00cc maxflow.c +9bb4b2a9897739e8de48eb17f130eb2d midend.c +58a3494e5f3e4bd60d4313df721cdd58 mines.c +b4da4a7675e6db6d031c44c93b08219d misc.c +3b3508bec8c6ee0c195215bec9e53638 net.c +fcb90d91433dc1546f5bd8fde1882aa1 netslide.c +01650cb06f2d7a2e767ef559768005f3 nullfe.c +6173395d81c3ca61484e87b517f94d28 nullgame.c +c23a3f15f0c5b7e852f1a31bc03b6f30 pattern.c +f70c787ab62b39c5006ec98749570151 pegs.c +d3d7de0f4c97211cd9b1d79d38972973 printing.c +b5e1c063a56529b9fd8467147bc8abc2 ps.c +39387b84c400e038ab73639618f986a8 random.c +17fb0d0357fb459c2930308ea1698cdb rect.c +086f42ead99b1fa87b5925315c0872c5 samegame.c +c24929370bae2acb6834cee18dd5be41 sixteen.c +19730de7a225a70b9546873a7307bd69 slant.c +c2669a6337dd40f7347e9fdc9a06b526 solo.c +0fadd9ff490dbee7765e93215191bb7b tents.c +391e2642b0800341837a8183c073e8d9 tree234.c +89d5445e988a86476852c05bf7305fb6 twiddle.c +87cab648c5449d8fa1180c0879716844 untangle.c +71ab8a59325fe1ae7defcb075479e445 version.c +45c5fd026b39fc580b79c957f3e35883 windows.c +2ee6558000ae6b1aaf5522d314b47c01 osx.m +4e7cf5a9fc13c537f1750d7ae8a2bd1f maxflow.h +dae425800dbe424c9200eb9037f1877f puzzles.h +d65a9dd5069cb8cab301a4fd8e190efa tree234.h +7498ef69793174b407dc44e89b82d9d2 devel.but +e06434c48b8a998d29bc8197113958b9 osx-help.but +fa91d137e047d06cd84eabe51ff1f856 puzzles.but +6cb2d5930db4df5fc962c58754e55d58 osx-info.plist +92ff899bb81ce16eb83f4bf2f87b191c osx.icns +f56ec6772dd1c7c367067bbea8ea1675 LICENCE +94a7a6d1895cb209c761f36fd94f1fcf README +316975fa15a27f7c3c9c70b86c62a6d5 Recipe +dcec1dc7e16968c87b0e9e8bc7d33d92 mkfiles.pl +7e0f997f3afccf4220e684f20c65106c Makefile +53e33e23ef2b1d106674e1652981a1a8 Makefile.cyg +6c90b15e1f16247c7198a187fb83735f Makefile.doc +e6c69040041f013508c1fc79d75b3e6a Makefile.osx +fab861efd29ec432bdef12aea93da110 Makefile.vc +27f33c301386a8b596976846519c0bce HACKING +70b8f2b97192a8fc5919f9513320388a puzzles.txt +233487a671083d726103c5605f5c86da puzzles.hlp +c5684e4659caaec9779af43af81b0110 puzzles.cnt diff --git a/puzzles.but b/puzzles.but index a6d2ef2..63bf3f0 100644 --- a/puzzles.but +++ b/puzzles.but @@ -30,7 +30,7 @@ See \k{licence} for the licence text in full. \cfg{html-local-head}{} -\versionid $Id$ +\versionid $Id: puzzles.but 6513 2006-01-08 18:18:11Z jacob $ \C{intro} Introduction diff --git a/puzzles.cnt b/puzzles.cnt new file mode 100644 index 0000000..edd9c5d --- /dev/null +++ b/puzzles.cnt @@ -0,0 +1,107 @@ +:Title Simon Tatham's Portable Puzzle Collection +1 Contents=Top +1 Chapter 1: Introduction +2 Chapter 1: Introduction=t00000000 +1 Chapter 2: Common features +2 Chapter 2: Common features=t00000001 +2 Section 2.1: Common actions=t00000002 +2 Section 2.2: Specifying games with the game ID=t00000003 +2 Section 2.3: The ‘Type’ menu=t00000004 +2 Section 2.4: Specifying game parameters on the command line=t00000005 +2 Section 2.5: Unix command-line options=t00000006 +1 Chapter 3: Net +2 Chapter 3: Net=games.net +2 Section 3.1: Net controls=t00000007 +2 Section 3.2: Net parameters=t00000008 +1 Chapter 4: Cube +2 Chapter 4: Cube=games.cube +2 Section 4.1: Cube controls=t00000009 +2 Section 4.2: Cube parameters=t00000010 +1 Chapter 5: Fifteen +2 Chapter 5: Fifteen=games.fifteen +2 Section 5.1: Fifteen controls=t00000011 +2 Section 5.2: Fifteen parameters=t00000012 +1 Chapter 6: Sixteen +2 Chapter 6: Sixteen=games.sixteen +2 Section 6.1: Sixteen controls=t00000013 +2 Section 6.2: Sixteen parameters=t00000014 +1 Chapter 7: Twiddle +2 Chapter 7: Twiddle=games.twiddle +2 Section 7.1: Twiddle controls=t00000015 +2 Section 7.2: Twiddle parameters=t00000016 +1 Chapter 8: Rectangles +2 Chapter 8: Rectangles=games.rectangles +2 Section 8.1: Rectangles controls=t00000017 +2 Section 8.2: Rectangles parameters=t00000018 +1 Chapter 9: Netslide +2 Chapter 9: Netslide=games.netslide +1 Chapter 10: Pattern +2 Chapter 10: Pattern=games.pattern +2 Section 10.1: Pattern controls=t00000019 +2 Section 10.2: Pattern parameters=t00000020 +1 Chapter 11: Solo +2 Chapter 11: Solo=games.solo +2 Section 11.1: Solo controls=t00000021 +2 Section 11.2: Solo parameters=t00000022 +1 Chapter 12: Mines +2 Chapter 12: Mines=games.mines +2 Section 12.1: Mines controls=t00000023 +2 Section 12.2: Mines parameters=t00000024 +1 Chapter 13: Same Game +2 Chapter 13: Same Game=games.samegame +2 Section 13.1: Same Game controls=t00000025 +2 Section 13.2: Same Game parameters=t00000026 +1 Chapter 14: Flip +2 Chapter 14: Flip=games.flip +2 Section 14.1: Flip controls=t00000027 +2 Section 14.2: Flip parameters=t00000028 +1 Chapter 15: Guess +2 Chapter 15: Guess=games.guess +2 Section 15.1: Guess controls=t00000029 +2 Section 15.2: Guess parameters=t00000030 +1 Chapter 16: Pegs +2 Chapter 16: Pegs=games.pegs +2 Section 16.1: Pegs controls=t00000031 +2 Section 16.2: Pegs parameters=t00000032 +1 Chapter 17: Dominosa +2 Chapter 17: Dominosa=games.dominosa +2 Section 17.1: Dominosa controls=t00000033 +2 Section 17.2: Dominosa parameters=t00000034 +1 Chapter 18: Untangle +2 Chapter 18: Untangle=games.untangle +2 Section 18.1: Untangle controls=t00000035 +2 Section 18.2: Untangle parameters=t00000036 +1 Chapter 19: Black Box +2 Chapter 19: Black Box=games.blackbox +2 Section 19.1: Black Box controls=t00000037 +2 Section 19.2: Black Box parameters=t00000038 +1 Chapter 20: Slant +2 Chapter 20: Slant=games.slant +2 Section 20.1: Slant controls=t00000039 +2 Section 20.2: Slant parameters=t00000040 +1 Chapter 21: Light Up +2 Chapter 21: Light Up=games.lightup +2 Section 21.1: Light Up controls=t00000041 +2 Section 21.2: Light Up parameters=t00000042 +1 Chapter 22: Map +2 Chapter 22: Map=games.map +2 Section 22.1: Map controls=t00000043 +2 Section 22.2: Map parameters=t00000044 +1 Chapter 23: Loopy +2 Chapter 23: Loopy=games.loopy +2 Section 23.1: Loopy controls=t00000045 +2 Section 23.2: Loopy parameters=t00000046 +1 Chapter 24: Inertia +2 Chapter 24: Inertia=games.inertia +2 Section 24.1: Inertia controls=t00000047 +2 Section 24.2: Inertia parameters=t00000048 +1 Chapter 25: Tents +2 Chapter 25: Tents=games.tents +2 Section 25.1: Tents controls=t00000049 +2 Section 25.2: Tents parameters=t00000050 +1 Chapter 26: Bridges +2 Chapter 26: Bridges=games.bridges +2 Section 26.1: Bridges controls=t00000051 +2 Section 26.2: Bridges parameters=t00000052 +1 Appendix A: Licence +2 Appendix A: Licence=t00000053 diff --git a/puzzles.hlp b/puzzles.hlp new file mode 100644 index 0000000000000000000000000000000000000000..3ea3e69406a1dca29b6bfa6ac8b136f59604a5a3 GIT binary patch literal 128694 zcwX$i378yLbuWHrktJE)fB+65q%dI5K&vH<7TY5Sw9AsU7)iz^CO}Ph%}iN6UG1)J zjm8Etw&fi#QZ|$D@*pNGfh4>KfxILT8{2F)keJ0Jzzcj%0wLs)kd1`J|MNTN+@*RM zjUgug_de@$xu?6T?mhS1bI(2debFn1%+22(Fptu|_y6mFS+&fVbLlc0M+c2rwr8E` z@$b<`2h4!kPk+rX+0UG&67$mK0}Sa*_Q7S}yKb5Jm4ChcXUzPmX7``J zclVpG8!|`l`}ckCzG2AB(dW#KL*^R#Jl71HYw2^xz_580eP&CC&8zA2Gs}m~Yv}W? zTZYXq(C71S8#eRw`OOte%ysnn-W5aUF8ch^%}dN%>GSe|Q_OGi@28lz(dW9GPcd(& z&$R)JL%KRFEzhSpVwZ$)Vzy6Z@hV_c{hC?zkZ4N6n*Yoy3BlWeXd%5ni-_ey~|ED&!x{V-*lRJ9)13|C8wKn>GQp(o^Dps=jQ89GvB4p zw_az=_vrH3f`+-lIqmTUizB`8o%>aG=;|+smkUsCeWzY=K z=S9nh%rJf4KV-~V&;8%8yl8mXJn8b=8!x+Q$o$ak=mV0!_|2gn1_rS6z57|FgolVjZT`CRj80!>=259t; zJ~~AI{}uXnwn&BzMe&2w^!3vG?UcZ^!+F3`;K(7l_Yigb~b;jCHC$!@x7Kd=+6j$Hj`vu z(xPwArEfdq8GUfjjNp4a$J=T_jlT)XR-87IQbcgkkN3%s8U6V&{MoK%hcUem(w9R?y@f9R6o1dA)hd%0R^6ew zh9iV8(D%#gDW>I1{HMT1cm9gLUQUS4W^=mvb^12ZW?cLO{aMLoXo*#6+Uf}{;D6Si zvU)U`#I1Id2Z#SES-sWFYWO-Fd@X^BqL9v)b>DSVe_Gc)T?1!z-3V61PjuZ3)bm2J{kdKD0@5GpzNy4t>bfJ8zPkH&CG&M%cZ9?*==HlL@r$}{dK%x< zeNQNUTi1;O;a=QzJ0#;h-FF>PU)p_7N&Hav9ii5O#2;xG2jGwX?tn@zmvrc=xZayEw*Q}mR(R=}* z2kENwxdfZj)eWk~(fD8Q<-R}2q-_S|}>qzJ8ehR+cqj8J# zZ}zz7G5-%e?gmWhpL^X_w)CAI_k=Nhuh$)AO_1w4@5zJ@_r7D<)3P47J%c)}*Ii*z zXZ5&MU{XKPUB?;)pL8?vg~T4*FDFuNE z>*_Xhz&-S5GpS*30_b zDy+3vF8GjNHr0in6QoTq_>f&?wFRH@>#ecibFvUx3qBK4=21ME)fj27;=kL?N)lBv zky-Hzn0qNwUQa(BqaWLKo`hTI&m%-5X$EAxmcGp<6M4#;!5iq?@vZH=mCc+eu@o3( zjg~z5OSpHCi6yOc-Mw?LKPP+Q-xL3y`1e@Z;?d(CP>u?F+ey3LLd;PfDi<@!SOpj5wd{r2K)`TI6@)ti3{Nk2vvaF8?JGL zN8oR`*YRoJVfVRN!S5n;0`1ugu5pB2AQS@O6KD_Z03L*2AXEZj8fYKSp*?&eL<8=1 zyn|=(J}!h_!2J%_y@dC$a zr4tVHi+(JQ@rh?~0bh6*V@GHO!W|IufiMh&jv%}OArc6yK63Fb0eT;T#Cz zK-dUEKM-Dm5DJ8eAXEb3B?#d_7zp~tSkM<>wlH*F3ymSfgQXRGN1OQj>4cp#K&@8& zOARdhO&A)1x!TaP>FbWKJhasihEH|Gy?l6uSt9QZo9CFVTSm^AXw_d4Ph{=ZIi+*X z-K>A`=g8f#PxPui|8+B{f)*}uU@xueH6A< zjyBh75#P=u*h`v6l4?16Y1XC|=Avqvx0>lhyOl&Ov|7z7ZPJ@bJEzVfQpl4g-AJOq z$yJ6sD2f}6q+U&rMw?mc$1{3AY9&Woq}fN4?OLsDhS&#a%$MIcU_J{IDFUcYQ!MYG z>#0V5J3yanfbjBi`2o|2f4K1$y5^U|iz?VO+dQU65t>z^>ok4vIdnx&o4B2PPPx~~(wCruQeq4a&b4$9$g^<%eO)*KcHQJ90 zz&!Jmu5lp%wofZe(_*gnzyOemQ@Vgb+-sj^n55aWLUc^mPZvGI^?6(apj(!9;Tl22y_*_i zk`^bB9~+=~Xld8j5JTLj8764wjq^+qz&w3f7gI!(bDx%ksN;}=0Lsgkb&U$4(|sCY zk{0iuU+;k9?YxEc4wBo!hk=ZuZ+YPnS5RjcL-g*$6b>Uam6NXAzo3|K55X$Gz~4^GOWa%_Pd{ zTdhjBqnQj}S$eA``QcX9h+5ek33x~1v<6vmoTQ#s%ZhT*90^vHxE?j=!FB^eP#n#& ze=$OA5u`s6mu9nwrKTncQ^Z+F0?VV>X@s+(iB^1=r0Hm)nZ$>q$!0b~_u^J^gs_m* za(QMJkXEy_K1D(vwM~PJ39wq8QCIbBE~!%UaVx@Gb5ScrJO%YlLLId{m1R|lu^=>z z*$1dI& z5lFkDxY;DWSAdG5p`VDLk=Ev-X1flUC$iRbiE%m| zAJKVgCPdCHdZtQ}Hi6Y3d7h>#vY~eo!9AOhOd4H2oz#I1f;$=^V5xIzpG5ci5o%$S zB-bV=p&+IU+`DML57P+g_S|^{7STvttzuMJ7kL3XhCQ8`NvbJLAi;(g9A3 zK-T!n&vZ+a#N7F!=0r_aTF_~Vkc4yqil51HOfhu`s*wq!n;UsXh{!+&E7O@qEpduW z4izjpO1h4VEUIM0_Zp-V&88qiCP1tG>7+Xplxfnd8TVMJ#pz5`X%aG8a8zpuQ%$^F z3JmoDgf`nGwW4R9uu1%u+s0|0N6;wN8BI)G8;;w=hno3x+TizeX5b;m8p2}bW^5xu z`V%CtM|pc1`&U$@Drm*48IUIti)TIkfoYHy{GSV)Ib zI9iTGPfg;wE*;Ao3715ht=3#L)2>VdJ*{a_1|Y+300iP$p?aDhN1xF|if~n+wdqh( zqN&APa--;8U$-njnZeg)p429JG30GLL5;~O6CN~`f&bEanj(^YGohz#gj`qBuJ{5$ z*Ea%e%`^Eb-GU^Q`9vC{kPB}LVjN05c3OAJf?JW9ZnYZYt5(g<&X$R9#zbjTv>nuG z4CSmjRc;?%^_qOD#d`cIo$^(N;QI}N2fIHI_JD`)Z+gLZX)TF!tO;g@2zLdiGI2dV zoYprrvWe_ynbxyWn*cKhW{bosrjuHOba=c#8&Or(V@#q@r3SK_6rPKQnJ=OBabtd- zph4U;FgLQrSxOoXxD435YRRw zDA>7GC8`?-jWb}w_J|vI(DmTTMQD6?nk+ zovm&TZ|UUO;1t>riANRU5riY#jI4T0fyPl2QVY8cVd=%x@Hs|+-L=gLu-jCC{a%*< zdr-O3Sb0qVdCWgzO;qVxZv^V!@eN+34Ss)t1{oCxeO#H$c##1CMz#UMoQN-v`aX7O zA3s>24^~USGmax-{e*<98*?>XG-V8NW4mkdn6~)n0xhoV0d)}L3u+Zk8AP`m^D??P zP;;9QpLY0j+M(&P$@vb~ixNv*UfW!WHZ`USQ-Ev)Xto&0#XFSp>t~1_0rNXdxVUkg zt`8q8%&DV&JEJ{GzqMNat?60-P>3QUV?y(~05)|mfRhl?Z_?whRyf!0bSvOLI#&Q# zgTBP14g&Y05sU6X|8W>rWV(4{IFiPZjg^aB{2YrEBu=Ib8I}u)4w%rDxkj+rzRI2z zVwhjv*_RcL?5{fkxP&%I^kET=3A>h6Na7+L2+|AD%VbR3Ro)^H39!7Rye}Le3I6RE zf`Ag%apd5f;6WWnvW^TA@>|}bO#|Ww)(liV;PKhSqL6?SMWX64pbRp>y3YnbMrA)Re51LLfO|5eYxE z%`;rTbFrJ}X9ciPvj@WPPfpT-Q3`PUgml1*ljb08#PnCEcUVpZk6GZr69KbAIUIB1(Ap5Nsi&IRtgVa=#I| z2XOoiwSS(p|FZ)f9e}rDfJ~6+jTjT>6o7tJuWzU$M7o5?-c?}Cw2xNOk~$9xQPXPT z^~0<~@jEH2b$ExlGRdr<0PE(W$JBlD>`}3RLL$NZe0GmxR@=Im73Lp|>N3Zue$M^% z3a~6}?E8&O-mblFN&H5~{GpwM*JBE^FliGpG(1gh&Y1YnZ(u8RV z{GNFLh#&0j$2_*Of%Yjx=HE2Z;gj||QvdVL#Z6DAi(()AL@jN|{t8n9%vY0|!jxx4 zg|vYTOej1=Aemaj=;vhR4DI7+2OY6|KbuU@_Lk@I6s>M)n|nSFrnoe(wDa5&HiN=@ z4>Wfm29`UT*nL@xr34W#b=`_?rIIt|(XtAl?uGmNv5JEnPj9XwUE*g41$XbePF{{i z=C2(N@#kj#5G~%EtxbV3f%of}xdvkaI}}IjSM3J11G+Pe5CZrJ{Fb8yxM3=QmBjO+ zScYottUxiFMCuv111Xa2THJ*A@j`_ha+`D|3YPYjv!NijIW(gsA^QM6w{zxViw%T@4A)LYO;Sow`7GHQ6vl@H1?^aW!&P|mx!O!6NFV> zj9!@~BtUPUjprB@iM4BA-A*fqX@)x&KysA!$Q1T6rP!pkl2%$JQO1K^u4SnvwgTuc z)2cipFD48-rF+t001gNG}kb_w7*kB~KBH(rwCQ|!U@JO)*C5yOKm>muT zsljqGSB?&LlZ7Q_kun%Eg9T=2K5#=#p~!+1V0b&XrVGLvpl)Rufi^jbrPQKHK_>IZ zjVz`Mk2zNQi@oHe8!eg^`aJGQ`n_hRIA z(SG-0x8J=u-0y%Z=%Ri0yREe>*PSPBG-_!@L2I6no!Lc zzj2F{~0*{<+nsH8dk zGH$f|KKtbuV^LK!-TedN2*8Z}&s&@mU}xxvVM`P2Jy!ZmU=)awl-IO(VgTmc0nJOA zr3PjNP0m=3MquM`Kn3U|^c1lf+t zpakT30~itI6vw&ITsiG1;?&gi=;%h43``!F*qG0;kFlDxNGL>98=>;q142fR-s;e~ zHAJTuxuz55(vrSPa!PA9k&T7dh6rP+wV0|cl@M~oZ!{cLSW8=QH$}!hk=2bQ^@2gc z{-`z(EJa3xnn7rURW!*AH6TK-^YP3I0m9#_!bKIxOzVwy%kB%>psI+f4rWa!hy~MS zH;E3%&^XZ~A#&w_(B(r~El{}uf^9TntYLedfps5SZyiWuZ#rA-qF@s8 zQQG3OZv1Anqag;su;`UEjTOr3a841~)dS2}O~Nbih!>DF z%HSuNj#(UUH-uqWFcr1jF3oF)y&`QXIVyc)c(cVA4PN$*Bx}@I7HYym%4Ssfm_tS+ zJ&lVU#Ty_3Jh9qRm)HlMJPa<^UCc_4tiq-kB8E}V_`zu`Uf70@kR%1|v)X1TrrEZH z#)Xjl@O0d2gChJoYN1*G3Qhd~G_uzAzupl-GSHV0cC|b?H?mwzDq>Bh(X`y6Vyub? zD9+D7AV2P^S;!`kb8Vj!@=iUO%^NYIKt^RR>A?iC5vF3pnG_b|q?6ojJWx$gDFTHx zK;)O)Emq!W!~9$?LJv8~0Y6tlvQQeP+A+;xD-nLy;P9hh+DRHkSrwIZ0aFV;XEi%p zuHTAW`g+leZ^2eNr2nk89Ly*7p}01cHL1}V_0oFhe>wx|#YzLUQje)joyp=?NbPC!mY~d0_<0T=IpJSpcRBSqTKxpc__lh?v8k^tSjdX|l zT|(?4ME6_|r2-W*)q~~G?8nMrSxt~FB`J(tX2~;rL?q=Y7Nn2i^LGuHtSN3sq^=8q zh9T^@TY~8cTU8Gj`@z?X(yB=_J>vZXG~*!%#{4Vc6qS!a$p3i1!|Sa>U3leqdT1y6 zB(f(COfhbrb?!a;j%%!X(&k=g*`&Ah-D%$}DdF1T`u0H%UL1A{zI$ra8Y=z{;mCb( z)Qk7WfdeHpV)8Z&X|$Qt5=aBWoP*j~#)U1?TGT)!3(E{gx!IRgyyOiFFtoK?Lvl2R za3d4%tV?qdb(qvJ4jAqN5qZrTGitk-k$Aj?$7{^xB#N#Xl$8W)h-%`M;b7LUcMf)S zi6c7HM>dGNJ(tM5JZT|{lLUN`oOPeE(qrsVy(1hTo2oUSmN!%$85$$fKE4^^Rs||* zClUm!%uHgU>=eodj9jt}apaWcNyiTn{S*H>q0_QarFHun41_svG)3(psBq+)@NftO zevBYAk;4ls)p7v0L`55S4KlwLdKC%VjwQFUWviLBCu$;TSvzDUz!>e5X+E7)9W{Xw zF?sPupC4wD@*a7&y?5vfS;4>68~3`fTB?#d*ApfztCuBY1NAq-NbdibTH#Rq%ckZo zF>>R~j~nyBPZUCP#u^xOL$%Fxb4RJ?yr&lNHW{3fONg9utw)l9jD?y>mOrbxj0p z!$s$CIExLep*GkoC)P8FC{4?|COk6}2|-jY7m0(Ss)vot)Jq>wqC0E3aXHMV7`gFb zy4u47Vf0p)>Gx!@TaS?@QzJHV%mBJqnw(#VCV!}qGMgZaaYhgJOOTZ)7i(H$w-xWv zjYe(GE`1lSui`T#-dEBR9v_e)%zx4mQ@ckLxmc}xgpXH~8ck(WqS!T{o1@~{Bpq(C zq5$X^8*LF)6PtT5E?=1W)ky_UVL_@ugJRV*SG`^1Yl5nEHpnN~=XbI1t-|&dMC!Ig z1o7quYt5O#6NpB)I}dg(eTVO&C0%S`=4WZnIPpNG)LB;Ge3-BkIAL z^f7bepXzJUzt~EIy1iC2=i1Tq4rcZRCL;5}3cVB{#lxZdmzj4_Qn$t*-2(*yJ;<&s ziNL=-AXIUV8L;BxWuf@UA(^*w@aL^cC4}oV$y?SOSJmu|RD2W!QM=K}+?*q;?VS7} z;~MF(8n1=j&`Am0Dk!nT_TA}0fL+A<4Z0c~lfZhPW9?pr#~_->jyj1Iq?@t&Jjr4% zFpk2B35KMZ0;2p#i<4V-Y6?hhKxE6fdVbNUUMcoZnCkXW6xQ; z_JR!;Y*@c;?EE!rHjJ${Cy06wo5ebbu9%iJJK{U5*CX<_IWcNO=@o1S+Y|+_~Gj<`PUGKoMvWGDpvx zAIlLX+KkOlEPFK*n*Zd8OrRKos$GjeV1wSd7aGwt1Q=9QV0s$1;|kYWg644L2@b zGGK1n9LjC$$D{rs@Q+bMJ7gq#Ayi1w0&M6{Cy;a^5?u2$%OYl-8QuUtqP;}y)& z4YFSY_uK_+2EfLeM{f1{m&4Mv#2Y0N%*^qtVhy(e`mh?1cMyYu@rhY3P^)d2ze05oXqF$XrPDhz{CjoTt%+>DhPM04vhbrumh{P)hzLd$yxb0wZ8#MjXXp zkdhYcClD*g@slo2({rIYj-y;=zg=#nz@X%sqB#^@wu47Ww8)5E034+oay`Uzd9!EU z6@4=X-fv|tbS5NV-Ic7zgeWLW0w9ulKo>U8Ss^w%WNt}C#Eu61f7ZYB68{n> zuGWda1Utu?vB<8sv7>9F^N*fC8@(#3HJZkJ+eq39Ao$4Xj?vuSo6!`lwW6?1NsyJD zhkc3nvyU+G(oGG~krD|UT6g}#=SQMycHh-#?p2E4{+IQi!6fF&{~v_5xJp$C4JE`W8P2kn{;&^Y%dcaGc8C?w(7 zb^{9ZDx4SqGa!!eg6$dbY&_G6M|V1yI<^&WOSA(AN>~a*a1`CZUY<_+okSvvo%BQN zTIHRm(1lUuXF61z+ldNnN-J$_GKq+{8OfFfsHbgm82MQDWcfW61UX5hU>#pwjNI~* z(38pw*Y+z^$HptIgkbP5S0Eq*WA&b{zir;+1h{7e1F{=kUWsWRg7o$}dT0tnK`(sD zkLFVyquE@AAt2|d`iXQ(w*bw6$ki*RY&qH!HxW0cQ4NxUWCuzw)4h$Nps46U4Xi1z zE{o)iW8nb(4>q|ed0OX`$mu!8+(P#!=mOx-GZgsyI*GFb$(Ap$^nsR2#7TK2@qR-; zPjH1OP%5n{Vk;v=O+GtA=SGGE8w-rZASb~5t<9D}}3?hA|68Dy(3T3ANd zZ9Hyx%r@q;5Kcn#Ck`s)VKR{y&R=7$cO*-zsMe8dv>Gh}ZR^>GtGgO#@DX2Af$+j)by>jB3`| zUYp~%-)3}GHldbVewba1oOk2`lN&g{PT3XG-_*E5=b zHmugNtbvL>921%5*b8GG62hudpSvg}5NvC@?Lr#Vxt-x!iToIx39JpUSa_w8Abybf z)!Q8>oGk7rL^?F_g>oWS$%L0{M^@!6LhC9T!YU;bRML>d#E33X<=u2?0f0@i0v{RZ zTL56K`7$C*Kq)pU<@5~90nI?Zp=0p#26WKjgj08z;^o%WknY+m0HWFE4-Y3 zz>SCK`pn*e5I$x`9=e`fiMG&Vpu)I&r`rSG z7R=rCT0%qDGE2syN(rTD2s=o`)e6wuf*F#U61yIyOVH1_6sJHEI6!~XPDe9`T)$QU z5}z*@}>%@1~ zT(FvUc2uRwsf*(~v^gaIZ=(xnIrb`ybh#I;ay5jIU=XZvnP`S0kY{7?c8 ziI^R;)(XX@@j|S%NZ)`Bp#q}25;Gt7soOx+9lPDsbf<0~1h#qqq4|(6FDQ`w?;5cV z1N@)8#3BC7PQ>r8OORD0=6_PUyqOZIlfvnFS9d{;yzAKvOxY&n?S!R&QU)3s4z`MN zjz26Z8VFvOEwlT!|&D8C{?dgT$Z` ztaa#Fq$ZiIbOBOqnW~`P6f8`xxWpbI)D6dAZS9vrC`@3USz~-4o(ru3ZfqGK3~T>B z-NFBac5o;XI1%Dh`T;lYr0W?sg**6|?BIbw@EG@SNDdKQ7$ut5J$%zbdw5SduWSefO#;2W~!q3aw={BGw~u-Q6wY)SpnpwdIJ1?4}lYqlgT# z0Aa&s^L2&bL(12jjV`MCjdQwl7^JeI`Xtb!dnOL;4EN9Ol9cL$E+*rJLAX8b;>DUZ zy<&7qc4x%nJ?YAGi$Dc#CMzXZfUym&pb(GGAt#z7LR}_DX{y4+UydNKM&FW;Sz(i+ z0yN=r>%9-s;*nDreL)k_97!C6<+BizfH?!ioDCT>5vb6k=_?v0VQVBxVG$7mXm(3s zbXDHrALLX(OUM)5XcJs{9I@ua6Xh6&wV^O2N$F*x&=)FG#0vh6V~zog6&b+xI!ns! zdU|!+le^*LuHm8qZDXfWOa6Z^x@Rn9?}N#hh_<94&_*iNi)^w}AVhHTp9`^K1HKk* z^8J@1Z}>w*`OHK*)rQsFhM-!xP~seHv;?C{>Q}cXS{&?dXIDzAT0xa1_iR!vV78VE z-fpJ(VH*bSyS0Yfh-8F3D{-O}o-j0Mv97rUL2vd|5aW6n%uh5~t0gvS(B?OS`^hmW z5F@aqU{AuV9lJ@zh=WTE8v$?#5DcxjaSvS&-|lUa>&E4X-9;NEvFl>zdxkcqLc>V6 z(BQh@%7J`-$D_plJ~Jqg++3vFbak@4N4uQy(b>Ts- z@*V9a@j}SoTsa1-A6xrKj6GPPO;9vD^#}2arNy^qgSEdQQRt|59)W#M)Y{2LRzE;_ z{2233&fB69s-=yU8Zoum6h*H;hyhOJMh@6&O*c8g`a-8lI|dE`oQun-FR6M}%ms9% zZY%i-z^eCX!C&jZF{J?u?%91c~866SVHOwYmOB-E`9op9hJ0Ei0)wBA_o?X@v zT7mxBE!jU zcMABy`rDm$*a&c<=G(D?`F3qNpW}4TN>;AKs~WVdbFAuB7!?0cY`FF;Bq038+nv!> z^GzNZ>T7ger!`O86W)Aid|g|>`mk@$*0sIvzW(ivx%LWHT&n{Dx`VG(=Dl&qu>OY= z++}5DNQVlo=N&>01jKBSG`Z&U@5CUKlNtM)Z7uIq*6sI$U3*>>tgL zYs~FNdIF@c^}Re;>}5}4t%STK*XN`bnabyS(1b`F*80Q?0cJ>>lwV7$qeSqtDDdh* zu%=%E<(FtJ*XhDwqdVMM{&J68i-7ls#aF7`I{~D7l$7&}(0jIs-H@bTWo}SSn<~|m zqy6$g$GVgd9a{Mk;DCi$*nxZtV2~^TAtfR^%0{Mg^b#EAf;>>5h>O6aT;V=ekF}sQ z_4X-WdQt=B0WkMQ5*;hQR-_I9(J3JzJ87mB{MLx8(a7=hPn4qL7vg_w@V~VuMlHcG z-XI56(|C$Go&_*4-GDT(P99&=&1;OD+J@Ob`)*yfw-3spi#Wg&?s?pppzE#=hs$qb=URw`+-8r!XL)MFBCwX`B#$5zdw#kpgcp)go>Iqd)6j zYtN)bfqe`ok)DCMrW=>i_38V)BC>wm)|XwpF0#qUnP)%`+EcnOchkM=1yt{j0eqPF z_qzrJp7ZW^>d58YN%hLfvszH72N;Kbt@R>n)?)aMZD@6%BA^RK7)ngvW zHpEc(SoiR{a0WL z98#q93h_deH%RQ&loK5OS4f@Un_9alozWH%;}$0Ti0w_l1S?0(M6(LBjn4@}J9ay> z6vQ+?5}K<(W7r=g;d@PKthBbY&W+Yno_%0#Y0bLQn)M~a?Hd@{;81=pT_A~T?spQ} z#VVm4?JJ?J7tu!PBNY0ODF6loD*3c;a*sASw?LC)VUq>9?|LK57BIf}Bf3^zOKSz2 z2Tlw|bS7@RiLNhyY#@Zwt(HZJep*wiYXL#(gij1ZLMOU_w)NjQ`l1M-gD+HgAN`2q z;jcQ00BCK#RtWT>R#p@RX|l4}I4+{2>o0%z#&O zZhy6Vwu^fVTQ+U1>klbZF^<*i#mv(>zDj{L3)N&-CPzsJtD_j<9M_fiRs+%cneXPD z?RlQ2p%=C`tO=+OL7jP|N?SPqSUmdyoy`lE80Kp@r5&jnxN!wtu^Dtb^oDU;0s67a z0l+faJGmTCJjS<9Ja@~W!1Iw$x^;PDApj9)3xm=(t2r{<&ehsm(f~KuCbh;AElx`t z#r)LuW>i8)(vAvfEfsU6!aXxgDRkGeHKLGCpCJPl1}$%|v}7Pb5S?O!KGZE7a8Qkp z>0{o={zRl4fM(=8u#Tscb;5SoWTW23@CZehvWPNsiMr1{o zo8seeXXd03w^r$7_JO2z4LgDfmsl+;JG;)C(I_WIuogzphMi-uHs`xZTchRR;7>W# zl1N*FO-b>n;6O4IacENW>~hoCkzH20#p#T)?^s)E@QzgJlN^cKTu`nrw(DjkF9`J_ zhLPKhg6^!a=rE0iopk(wJIRp=i)RbKq;i^}v>KkC$lNhV=;z9;>5;U>XN2G#cq_K8#a*4Dr z%Dzf3{E@jK{KB(TvC@v__MoqKYzRf4Qt2 z9RP{?=6#c?D_-Hk-CP5Kd}b%($0MHsl>Qd#AJLK2L=+d%jHeteG=8wb(6kyGDx6(TBfsM-#%=uZvL6Jl;*U;K)?D4ZE5Uo~I z1y#(Xbs3LsUNgZu+s53bQV6((Xe13yDIT>WhdJ2ub=Zu)l9_=;oC=J=4Hp4XtoX=A zed(DSmPsx7d+;)1v)AgPaVv;K;M(1Or=@0*=7sW0^{JL-Qc6gKswv>z^K@Og#j zie-aV9xEJo@W_)czrDdh3Gx<`BukbnNj?Zjbs1UDx}HZEAPIr7_v+s9KYb{!C^{`JIm@SC)ZJz% zKv+z>`t;UYtwn#*R(TX=Zt-o|kQrN<$UC;&D0d_G4*96=&)KGh-VyPZhV z5>YNS&FXVDe^SP7MMgHd#dxvyTJ$+57>o?#vUGX@j!Y; zAqSSuS?>qj6ATIVeWW4O6Ft&Iear#tm`M`2dB02}`~Y1*++X<-XWi_oxb|nbQa5^b zN})@eT>J1^Nb7veyu8(720tS~P>hS9f}0Pb%BmWc%Igj(qH{W+B0?qIsPH!9Qwsws zK8<;ck$@0P<&9@Jsq{O=v2FFrf@&&VsbkutdZl;*3+ZO%sJjvI$8@}pI^galuXO

sWyK zfcN~o!hB$po8Ld|SgrO=d*B9VBHyR)01&Y5tUj4ewN)IqCS!Y`P-i{ZZk=RY1hq|c zq2)iJmN{nk`2@uLNmK;ex5yW>?8_E^I+KtRdQf7!Ecxh&H^LCsZFZf#;W2h**P*VW z3EttPWV%wUTf5Zh-(yptCTG@r{QpYxh!!=bOr?#_--zT4eUCFeb{Z@z8cMY5rt$s3XjtBY)lCYf6rHO92 z3v+b{tlQ@&0^2)F$3E{(t&cW{A*wdxS+>LAG#ks8e2Bvga5bUcx|H+sHTbI|v(iaB zZPKlG(gmsl=TQ{g@nhGoEwkvYU(<}uv@2RX@(IoQ|8mW`VI+4AYcAiR`{9x$hQ-#q zZW(4x7&qQe*U?M7W_`hU@6sfzbJyA`M2pu~M zREv)bY}sh1Nmp`-eK%TYljm_H9@P!Oy7u7mgO5l z1kcqdkfF?17gI1`M2B{?OhoZ@!tVQV5r)m~LF;LrDO7j9_XGPrc&q#$vqcT0TqrK` zO5Ri^>lA(OjvH}3aTSP&7f;34U^(tf4`;PBGFPtsd9yLv1uvLXTN1C$rEzVhqf!d? zV@b}zT{!N{mFs@qlp_svFWkdXHifqf0q?y}PqQbjOXMpDyP_%=6G!p{g`7BG2v9Db51S8A~Qv=Mm_RP+ho!+duS>xw<-t~k~7J*>*p z!|~zvss>SnbcH@@Wq90CP!<7=7)5l6Q|tE$TY2O)ebxF4L=E=*B{UXXVWf0FAV2C` zJ)o`r!UC<1b+lTr7ohUgK%buOP(WPfoJjY@e(`cAH|Mpox?(AFALuCqnm88FjP}1d&Qw(^M9X zG!u<};*O7s%+3%ff1shqSFc80yO+|1VSR3&lJs+z8I~cwMgj%$Kyl-F`v=XEn?sTw zE0FZ!ROY31(#@NO4R!nBI<=!s|{fX@V~y_P1@re!fuNZU<6;-Kls>+5p1D{ zpGgtDJAc<@XA%YwDVF9lEKP9Km<=0~vK}r4OaGR>q4wcu;C`BDsx8vNfklWSeKfP=73i|i5WpSRra%Rpgew+U;s?gLmGOH3Hon04BF^^7kX~z{E#;$ zNYlZT0khX6%`D8-55^|ypjae>fmz|YFc_!8Ft_DXUpP!=vfUIdP&M#eq?uljh+eh2 zyq?)x01^wiF89E8&0tt2C`c3OXFA3i_fveR5m%7ZV-S4>1h#%i2osLB&28CUIRLTH z@Yt%gexPZ+0~Q%>FCZXi^D(;oqAmKZ(`iE<11h8$tBj1kBZ;*poL^$?$A0OHoP^yL^Pb6MK zPfM4uxdJ!dN7t3Nc?-yeTrY_eTo!Nt*i4Nz_bN4Uwo?*pgw4rDI;N6UY9NnvhVB&(J3*{qS&HLcOBd$jpKlcsqB$uX(Sc%|w{jSzJq*iB zhdeid?8qaxfgW0wS`8_gcvk&HSx`_)Yn0bxab`TIW1P%{a?Owrfe}!%vbtkMan{ls z$LBIOQkuX->!_xM6W(Yh4x~f?&1$qIBbHKFRY1qbZ_`!vongbez&BScF+W8=;Kr%9 z51M=K@T+Rg>hb7Ow$nd`fPK5FuG9ukzN*%&#c& z|5yY7t=SDRK~mABFm%?Gy3pllOTuOyvDzWLGZ1BBHv8rho1LgN*OiiJw&iGXX|WKn z&wi`fjj+QXNo=E4g}ChRDd9Gr4r79%3t4<+K&T3?xS-k5B9FJdTGq}h#3Bq zE)c`h?{Gm}Z|NCS@3(ZjUuU`#vBJ_}eUHOJ^NqC9(mJ6qK8utb*4ofg?=3zo*qsDu zhmiVW+TM5>3JwJWr`8%{VS{~nwJbX<+q^S)X6*)Z8&BGt#>1KNO)e0Ux2L8Or6Lwn zRB^L0_iJ zYgUVSOxa3kO0)(_(9%73bQvh$y-=HDVVea*;tfXXhXBe;?^Z7Rk|D!#%kk@%uoVC| z-bB~i?j0;ZIv(AlukmLm%nMjw8uDxx8%DbNbLc{Q=uz45j&3%5a*SDPBH;Vl-9M5w z@h52={}a6qkj#f2@A+DPYhoJYz_U`plnEUie60{+U%ao3U9}t*=wlp|)}p_HBDL&a zwS|X?OHL!fn@brWNXU zmt@QZgqSDO1^ixcuS3l9dhB}aX)oGOi=jd`yQ>&8xJ!|3n4U#H>sPBF}9zjX5wgYxyb@p-y-J{U-} zNM$18TD&+5a|A+0S88jD?B_2a&PvV_dNB_f(MSNxJ3iu8^-DY0T_DRAs(rYaUU6%y zJ6j*YDwl=9RX#XYiUfr1kTUfV8~Ea-Uzd_P1rISMYmM~^hcS@e^ju8e5S<062QJS1 zs0;LBKV{Fr81<;5&aL&OJA+A9kxHVK#CgmaGEo?zvjAyxzME@K(oHez|1tH1!923~ zo+LDF@g0?Yg)5Aw{xP?WKG;nQOaYuOAcum=q}U({sDU+-);1P{YpgcT3Pe!&)xM@a zD=y{oAJp|{>B4}gKkn%AogH*}DA>bP`nMi01l5kj(S;9RXivcsnki6f9s3EM6yhB1 zsJE}t{E|e=l-W(tp`pSOe%-}w5Guw5kPQ!S5Ot@xRMMl=|CsCFm~)6(e}hJg3ApVO zgX~d>UO4}`0=o;&&6&5S=QwLA!yFgzVKYmwZl~Cqyjk=@nS3>42bMJX+1aOS2}i@( zDT`~3>3AY(m80N)z}=>@CSw?CA8_0|QHMA$`aFv)sU=X9wYTx-A|(AUTs znC&zd*O65Z>&a~1h#SC3r*?U;UCj=+<)H9`?PwdmlzjjNCiSid77CzPzlZ>eH9Z0- z>=7?O%0EBg^ac&=f8?(Idc&Hs+Y>@X#O720T{>ede#o$l@M%fz|rFM`iob@d_zf;>kdC~bkn870bo&vh+ zQ;t3TdnbF+yazc8xe%c5bPm=Z5EmeoUxb5rrygtqb~{9z0k1kne2W?%MN-c?-?)VWoIz?;DURJMW*3u6)_I1L@AJYXiKmF5g zkY3< zMThGo5=lA=qI5Bd7$DY8u|Yc-L9}@Y3#^E4<8Y3g0I9JRB{W!(JvVb=-AZb?K!ZXK z5=_V3h7aBXNGk@0teo=xuEm!$V=g@gvr(-u#U)WdJ*kDH0%DuflQ?;{mBOql{Fl_< z|1yTr@r?mD=XuBKhcZ{7sscsR#o$%tNJI9ag&|7SPFiOzxA&8>Otn~AM@GN9&yH1J zSc-QzK~M-}ps@nA;J}Zs#`+7?Iuu4A@?q+YH-syf8dj73Zs{q^uyNy@p&>JNYGFed z(+y#9>T1s|!6w69p*@^D8Lsc%mJ%D-Iv~K_KJ3Wi<_=cC?{O(pXOj$aOlBcPZ&dgasv;xyjSh!5}4_O}ofQW6o=rG5|rq;(Bma~fSa8aWi`Ua{&G60;g{ z+l)v9|EW7{39MnIa@_rVI1+?IjM;H}o+@ zG0hdzcx-G?J~uvxwOTk2!5)3ZJ=@TU z85(Pzh6eed#Y%9N2ViEKwQyfnr6QKr3uWIX66@wiS#SyOgGF82bXm&kB1CtSO=9|d z7>iX5ZLM(Wq*yWh2ZP2ugd7v1<$qWroN$8Qkmu`3tlA}Uy{|Ww!^}a<|Mlb8yC9cUc6cqbCxDA z51OisZJ~O2bDVdad8VWSH-(&!T$hAYzb}@sLaSXvI(|qZNmQrVg5=c`XshYZ%yPSg zMW%I~sdYs6GrKLd^th=RaV;i*9={&n6`YiHLPv{UCz3fNR-tvj+H8~$j{q8=#bl5+ z502h4p_S9_PfnZUiQE_lb*px~AyE7tmrFb7Fp zyfbk)0(KS!Wt{9_VsRSjElrUFb>Rv{@!>8SIp|pe4>Y{bdgL+HaReq!q_;}5OO4G4m{se9u}wm zPe@t;jAIc!+Xd+&-fXkEC)mWL8*>|?AqNDSsnZ;*``}pUtz(}f$r4xSuH?*O!agjsg@m0;cnfe@ z%}~6Y#W>%T|(3fS)kG+N}orD)`Rh^oZEMLpMBXelR`Kv9u;PdlXCmN6!eD0 zSL{m~z+){qrEp|76D5x`3i?z}n|1!P?aZx0a;_|EW2f0hPk=6IT3jP(5*f%AuFMqGlzA@dkYNv_8lRQ6*kxFk$bA@2%Thz{ zcDg_;_n+Yi=IMQ^H>ZVjtkae~JfmH2^P$A3+?6y@J~_;-w2}HQoDmi@PD|v1T+Et_ zCh%CIit9cw5ECT6Yd#H%?i%KZMk^f1L`IO^95an;v(Qqp5%H0Tnd}A3ML^gz&n~W+ zU#Lr~Y{Q@w8l%d`131;wh%ho}U5AdOC5Oj`K5qtG_{OOzc3+FG3TU_5Xti z4*M3Z|Nm_Zwdgre(MD!fB0zZBCS{zzxy-OSwC?6pSYg49m(caQ7Y`MnRMxpDBN?N# zi)@fRxv3YR9G-gT&pmDspt^Vs8gwZxN&7H^ljL;>Vt>uVuPRZBplQF{m? z_#*LfRC4+TA?FY10`gDWHe?;OS9kNoPQzcvY}6y;kZ!t=bzH2F65w?rz)W~};J7QC zA|nUCwMI2tO&i!Qo)D69E;_iJoZ-j(MK^609&MF^j{V-1wU?+4^$W}Hj9#XaY7cS( z3w72uY>tP$-HlmfR&l|$wqv`qa&TMha8tCqA?BL8;dj~Y$!Xse5pm-qsP&{F*ezQC zC)4x<6-8;PRZ_4cgxom69z>ey2F>y|DB!dNUbWrrez*1%mll>RFfoKEqa(AHxL{IL zTCkE8&x7pZ*#zred>Y$i5(-Qb`)XlNB_cg2A_3~qGox5DXMuK_mApdV43yH9oj@+T zt73C8WNsrG=g2&$V%}QUIrLIw14rsOrVIJl+<1mIk-tw94ED z2g_kU-%2WeVe=%|Skyj9am-eqWcQu(aOx$tpntgd}B zfZ{1!9+~@d{JAOemQ|Rc#*eaNz|mA7N(Hs5d5?5V#MU?=T1BJMVO1EZBo&b!nQBrI zb8$%E_tS*`ce+4m5H6GeUevM2jo3{tVfE0~l5*UOGnfcPK3uX8GtzTPf6LOlnrkL2GPeN!W;VvgjXB!nF8K#?sAgNot;8b@}Cm#H0~2h8Svdhk1e4T zj0yq!fb^=}LpGswgTCw%N;^)s_9`F(Tu9jEo_}?>8}3;_@ASTE?xz#0`U*XOp5A)N zkj{%aot0=UPb59GD%VtBW|%uNV~S~|6Y_S0IgevY*WU((@3Zsu(o&4 zkWK7dGSGqhEy&3e1GuIFI)2Kdqh>QUN3mUwjSu)ndr2L7r*6ZJ(ZMp6qkuc0XI(QV z39T}1b+MT3uadpe&48vFk3FSwN zj;Tq;EN7+pVK@wWiJ}^qsx(lsutPL#|WIT$uGd=bLSm0x{_ZeI~rh=;HOy}Z>zV% zqq1yTHH;@}^RgU8Pm6CkdrLjDz9&)+c;PlNF@Oj2tO$eJHY&nT#wz&73D&#l!n1$x zVc*#S`vF%E!=kVf({7$CQj15zv-?JiWVIXPHtJ5|8o(Xe%zCVbH3^xHqvJ<7@M|o6+^Ji&toPDDh$y)f4F-JRI>(>pi{o%4yvWSA-H;cei{s`IjtsYH9>CN) zt{du1^LTrI)6rTDN^<=N1}R&I24G`(chsSI$3m@+6W}$U?B|W(9lv1~<+B$p^>2 zo?1=m0=ysdy*$)&K^G!BNOKf7QBu{F!e$VglkV<~sMmH*_<>83;y~Y)K9|bDS|^Ou zmce*`?wEt-FHQyxOCUXfv1+kchpL{9G_YAE~b#8-4lMiITO7Ib^h^n~9g~5XYKX%Rkyp*w~|@sYH$h z{RA2<_pt_jxL(6vW;54^HmilxVMZ32OC@FdmOR!>YF1$mgycXa1lr$t+hb4(@1zHt zbOG~gZg<50R~^XTRjl^`YM?y?8&(0qDB?U?3RE#s&Fq#kMMI8>5hq$M2%7`Sr^1_A zsIX$pw}>J>Ocw?N_NSJK8+%uJ(d~`Xzf(S>E~sv!&}2<-A#6zyn1e@9q8fI-(Qbn{ zklChzw|c0yD(|~7jCsnLboBr@(>gFZSbr3h-e^Rk*yho1y{di<`8oT6tf1W=1IRL4792i zXq;@-Y_;ob)8M72F*r=CIkTZTA47=vd8uN=Ii^6rf>`z`e;~ozU#HvQ9fO8tV>7>$ zxdLu{oUU{44)pGI<+E~2GZBzatZEX=Lf9tT{aWAGsGgB_U8Zmtb+$H+x=my^stsNuYE1120h7UZrtF zC%_*`lgFR7R|&Im_VOw`GbOdExR3)8=h!d7);DRLNM|;wq1F@3$S{EI$Q6Ifys57PKo&B}Bb$VDbn(C3# zgVBHrJ5qXnyKjRZ)fYf?)cBZdyk~k3p1$jDT?IQxON2mp?e$AJ>j^i$N!Q=rJ5+#I z*1@6_L|~|Ide6Dq{vy(QdSl6IBmnflJ&%`O_y<= zjX2MyqHQDfCg_wE(A-%q(p3B8+opG3pMwfa*n`sAV`dQ zy$(czHS_rDbvF74Q#*a1F5zWEhBvW0k1ge8g&XgstMSpo5+2hfyf~Gv=OVTV85k&f zSVTfbKW=0-IRHC)|BqXf1Mrjg|B#v-zfn-4# z^Q!|A(1GqSovOWjwNraJBnC|>cIHk<&=^W?&jpXLHN({gz%)0+sZj_{q8&a={1WH6 z6U4PI1w5A#7M_9_YmKm{z2- z(bJg3FMU*(;fi6yyXcKKFE!7nA8_NRJ~m{&_CO#{t{;zfa){@m1xgz|-O%P15k0*g zD^9v$v)ZpJG++3b+sIb+_upt@fOD`kk|~YRw_Y2Zf}C*>1fTEW=nbdnUEQ|j3t9-? z8Bt6J86s^2Ohg)T97mO;85~H?3kQ(%g83o=`}T4Sg|IoUg#*LtN?O%R>B5|R}%-M#jrgV@Ni zp`d}y4>-now1_LF_#e*QV`Gmo6TkRCSM2e-`it`GMM#ytd&C|C+^;>*6?^>fLM@K@ z7JJ4X1H#D%mF-+}is7CA^ucAko#DoN==$d1Z~;nXJd2Xx8S`D7$VL`pIOt&!k;Q$m zV`X^2`m|3zUNZa!T3%<-1z7id$}O>HcPueyVB_~nQhh2e@INnTw3_jp6)o5SGtEji z7dDmZ&@Q#j<^ee7q8=Yc?na?}mxwsQ=TLDlD)(g{<_uvNe{?aha*#FVgu5aGo8#zd zD-2?Qsc9XCSgRN=+oA)jCGn6Fho9Du#5Fdv{t;p6m+8X1Ed8{@+6y}U#KlbJUSmYb z63*;LRkRbrt(rP;7O#0f;gV@`&ztg!$GK2Db|EJc&a3Tn3>w}|IW6omnrzzGc(SL> zum$}U9TUDe3=JyzZNk!#s3UwVq84)twKJtfYa90^U6Lth##TN5{8u@slmIt4UwhU8Q8hiH{ebuyYs8 z4k36CA@^KtT-4wD1{{L-cCIK}SVpEP^+#L?YP5nr>IPJ~U@((}oqHFqkyJN&p;Xpf zE+=|uhyvPTw9E7efz0>`jhm<(#hB-H6#4^uBYHGYal7cbBr6ZHF_)baLhhtWK_Rb1 z+&Ern;)KWLCkS_MHHPQyHG>Y9yZXeESUJP5Uu(J3_2ku3hskQ1E6bcnYA7YE;jlra zOv_e)RV7U^13;A;?a{2|RuZLKIG_X+fnDeERe@plgIf_en;9CGO|ZGdu-tuO$uc&1 z;Ku)=>o1oTHo-Bw2`)|t?!67#=ur$6eJmn+wC|RFH@)#|3h&&oBZBqaj_?0OHMpS5 z@%~Dzwlb~iV$jQ^Zm4~vNSb;`HK)=AJiLS8*Nyxq9QXs`TT`dx5uG~>^;t`Xtp@#O zeZ1QzX@$oE9fF^z{ze1eD8nBU;W8SLV+(Rlq=k~`9ftt$&=Ln^hvV>4D~U=99vfrf z76P1a_ptt4UsxN326_Qvu>~MLzoZ|wcFK~Jb%j%g(EGMi90YIZ3xQqCVT2tri#yPV z@GExK7Jyqvt)EF306Th$1MXQx;5I|zhf-8OoXhb}h=~Jq`9?i z=7cR%7xS8EsUJ#_$5kBCmaEG!k+44R1L)OD1~aM8b7b9~WAdwEv*GwhHDv@&kam-+ z>X3xwqfH4F$Bn4?K*Lv-I#hh2xG2M;A7LuUk{l_+vBywB6}0_(F6@Kz6Dh%5VpA+U zbF`Z@tq5B7C-(ryXD@RAo!e_}s_jNiveS(DC_VRPx-bZ^LY<$@edeb?CN5S;scKY2 zPjTnjbs5HFRyYWgLue{+@mcc|ha2mDJEBPq9PQ|+PqxfpLh8l&uGaH*TTp&sGe3OUQ=t2OTBu9kgwX5O^%lD8EC4Vp)@#T5p z@@=}(y)Y2abjHz2d_>eXrbL9$0 zx*Z{HPSwLgce&oQf{znokwuac*)@|BT=&}r)CK*Mn2Ps;tngf&>Lhy3a2y7=8My5* zL9Zc*I^1@j>aUq^&>GhmYY(>_hWBT_LF=~r^g<1exdwZ>>Hy!q)0E=BO%x9S=Z(vk z@tMN7@vC%gI&-)HqtN`K6n#uvUsoN*g7z2Ts_TszRBb?MY5@8#r@Q5Fb*GIhi+U-p z#Ux_c<@+hJY*t2Gynh%YMBfJoKiT}!!c_!?U42<4>t|FV&Co0y`9&T!bx zI+)E%WQ8;T&4Unp@RNX>aJeb)q0o5B*eOSwU2QTBRp;l~R44ee#a{w})az&x#x$-$ zUf3um@>X1_B>^a0X?QjxolBhlfldLk0ewHdI)yc?0gZohrY^VTLxwk(?_IZymo#oX zZPT#%?3TiE8`I^sIF+L3g0pV5P1?gE+-gP6VL?L!-7YrVeeEX4dVfqVHo)`oO~a4P z#Rg{w&hG-a%Qica*Ph?i&&4Km>K$z8cYL!OafgF#iG_!I<7cEt#7YS)zW;L-`L(pH4`M#He**$SYVfYP#7=^)%g!f zfI2N@>sk|DgnOQ}df|>h=sSNr+Ln=qn&t801-~syc_0F`sB3U+0m1KltU%Y3 zxp_d29|BCLZFl_m-cIWy@k*RBWBqJZZh$8IS1ejej3bn;j%_7yM&$_YJdl@@>L{(( zwCVjUxh&JwK;;H%2-)&nAXzgPX^{{yab;{&i(*zExq}fnlunki%B87R98f>5Yt9}x z&PGwYQ@H`qmzg}N!I)@wsjgGjsZ*||*RJTfczUP+c2b7b+2=a2)5^q3A#XJ^snd;j z<^nvFB^L(%B240m?T!b0xQD=L%T2@fSVh!pg%3X$!|r|}ecJk}wM0+9Y_UpeRZ2c^ z9TpK~kaC_E3l4w+**G8o5W?5CJDG5g%7lN~UnV?XL@7&Gp`eL~e#B^DSfF@q^ipl~ z&lYNQtk7sd*u2q*y9#jLyF*vn2Wh2Y=ey{pW&8tfoV9b<%v%F^NA{si4%C0eWnMTeSm8slnh`r4p|A5yC|6u@$)QM*OJj8~N~ z)_Uq2gXkGv>UayS|5 ziZDIR!A^ka4;OBw)*CDsbmR^uKtz|;Op^jGEM03hq@bX?fNmk<1}Fh|f&7Ts2gyFZ z^5e}$G6sS0rMqf7`dU_Nh; zlj;7t)9O`7`3Mg%k$r)qDwLn*5Z%SbF`(dwf~~CaeeKdANrKs|NozXYlUXa z?$Le9i2i`Ka%|(*nB`_I{eT;PNY_Qz1w!)$dmX$^FgOGqW-au{W(I;1g@`45#4&c7_ zMkR+$XBl3~FTPTB1-J=LGZpS zK2hvGh3XwQxjpdK1-yn6v^$8TJ)Kso2|M+jMTZZ5iBYpgb~+mhP_>2YlAuPhqFx## z#80NI($enY%u2z-f^~_*mlwGoW(wH^y}~yCX(=>HDgfRiH~1E6df(Uv?gs&ry@NfPc+8?qa1`;fNCVRB|jzoncquhlI9fBh}-p= z1QAX$co@83A+3j=#mNlLan25m=kjq8SK!seRIR*a`2TC~+k@n~$~*5!8og~u*xDr| zi?0nf8W^>tmi&@{cr1;iu|_juX5sFdiyCl9bAu#VCb5W{p`j00j;WDF4F{o7+Nd zuG%IdX)DBiE+$FK`qVX&%4!XGA%r+72*G?UJy?K8Pp-0>g^!*Qe2v=TQOxGnptHQ0 zFA3EZvID+b^Z4qm^pAx`k~mK}OXCAQ-A(iWg*)$eV0`r4!Ds}@NCl2&Ww9bUPY;oT z0hkMtC^lF2dlXy@|2cjn8uP%63ZTtl4vuryl|%)1`-^p;5G0^ z^Z*lo_<-9~zj@|OrA06p5~Q;7Gu83}oHEY{sU8eg;4Ueu$Vp$aX2+~dROK!fH25G zF6;5~ub-?^V-1Prl7nz517P6Aie7j2SAcZN29SI-K)>@av!30p2 z#kB2?>I>R-#V*saR9h2I6fHubSB+!;6j7Y84>&?Iv*56>WRT7sNsz;#;Qgtv)>|L$ zf}r$+9l92~sJuqmtAR;$%ET!od{4P6+Im2q3WD z@e9RH`26U&$UE`2sr^%%=@a_~fc|u^26q$+lk~qr;SS#by+7WoL9w8p?Y;qe|C?n- zkWVlIdcX9oXVCz?U*D_2_AU+3`+a8^VKQuh-v3jt2K&2=fZo5q{0Nh-!A5$}`->iN zJL!dPC+W%+H&5-Sm7|vjM8|;Mi=TC8?JIfSN_U8>L1FqFNs(y;kr=E5sybJGP)QQ+ zNhP;-8(`yZY9@)OlD5N=YPZp_b&2qg*^sdLWMNs)x*^{?AYj!u6FN?iatf%x?7)QX zKOM%WWVj+N{skIz@qk!K&~o}QhnN48!;ANEgjGZ{2J;1M@U`L{dK6s^93rY|ZF5e4 zD28s&OxYPHPNxm_PO|A&n$A7aB`X%2vdi6Yxe+>9smh{TD`s)UIXNgVL9~3nC1ecm zZ*s4DY7)A<5W|MbVJjy(ZKO;< z?~gvQ%1R@2NtqyjQtQ2`<{*}uSUx#O&s&gpB5UiIx94wTGl@04*KMScwJIE=K_h7r zxoJk`&S5dMFQYR+=SHI7ptA1l4d?CG2}loqUUe6RbrGwv zMjl)jT}fZyhu@*+_GeaQpbfMaed!`Ouz5B;)-#PKW`=?KNaMK-vaB8?z+Ul`yJ+(D zAZJpM^h?6J4R;iQu|z07$zzASFIS8nmo7n2L2AoFtilB@E%+|ZGS81~b+j@Ehb0X+ zXytnpsa%o*4IwVNS{4)i(cscmUYQ%Xa5g!877dni$W_S~DO^a+!=3<9DUx}1mO)(V zaYYYmWYpQwUn)aDc6E!1=i2i?V5Cjyj$s?Uqec#Kv*< za^dTg3t>9gLRJ<&awRpYI1i!_BKE~(r7B;>=t;nV8K(ypG9x0p+?0oW7MX5{ zV8AlLue?KMX@^`v54QFN&p7|2#Z?{Lmft7kWKIL@*-@fhkLO%X-5~3}gs)1;kyaW9 z)o84Sab^j*egba*Gl02V9;yM6Q`C8pl$w^DJS2t?U1~l0U`6wY53s{^t^TDV1^eAdA9!SkKMVp+jVgKH^{n-e`44^ zvMw*nn3^LPhWI)?&y6FP1rlHezdSH_c7X)2GA%|CgZmL`%tGA`7j_o-Dmh})D{mLL zO6EM1xETM}SjWQObTHFCbL=mdQG#EiCbbdmvHn}wfPxRU#k~Gvz+p5OY^yn)`QS&< z`{`aiK@X;bjbsI6GC6Bcgmzh>7%lTNHJd3XN0*FY>Z6n`T0QJS7KoMEWEJmCtc#B< z)#=a=i@(&V;^r$(>oL#e9m{hg4vsVn2U`a~s@?r>25l<}Qwho&J5FX<)@N62k;Lt$ zD9e0|g1)MJm^s^Igl4%KOLKEcy;b7UX%%1QPe@m#R!6V|8$R1D{yX2j1)m)Z3;Pc% zl_cz16|o4H46f&N%J|{xRfEyxYX_ZWxVUv^JY6l-TK$`!Ej!p-wYxKC2P2o zuS8PS7tpL895jAyGRJJ*l=jLu+YurPcPmxlv&S2IM754I*p?6k708y+JeO9;eMw8d zqfHYKdgm%&-fIu(f+`1$7!jPEB9?4kQ=JKX(u@~v4 znImnm0`U$;F@#8%brKQVm{pL7o1ngY{FbDVc6*(syNL4g5~A~Vc3Nj05(cPSb@}im zA9}C7f@lbud}>X;_bcUc)k);MPrMZEjHQ7P9$UAJ=OM95LzjZZyLgSG__u^Nck`kb zd>c3SZVuH@x!A{YENHCAMCI1BT8X2ZuY7$J@B~=CM|{sAPvGj1Q4{CqcJ%1cLXEpB z%%z1l)wigx>Xz+SZz29XIaWB*T8uce+jXUSiB>Ne^4Y{Nhwspn%O>_GJ@rGyty&KS zdq31TSvE1i4vLY>Cbr_qWqK_79=m1}1B8#RRWkKK;#|PB99+AeL+MQ?7 zuR{iOj;Gh~hiXz{C*44nrz@h66p&hnfAI;!(z@t`(lA-BwVX{`$ehRQ>rh8@!yCfF7Y1|KghN-Q)>Z&S zs@ME%p}Jvi3F1iLi5p95briq1MV!BD~SEi=HD$i~SGz;v9bGpu-CW`#f~+S*zY)-&#sVjXC!%hus6Q5QAx$Sh*W@^iH@&lb_YLfzF;tV z=$Z_vC>p8gPr&I;EG*~J8+D8`=UnPd_)MAsyzjZ-xt3-C{hwcOmeR~fB$C7>TN!2XXPy?^mp%;!+>dnXz7fVSV+Q&5h zcs60)$|(b#Pb8;>aKs0_2Q@Na0oP&(n_&IRSjwc7a*&lMEWpD1Pgx|k=anlB*`vdV z>ve~_oFaSBQqr>ez|8d0AMSk)4Hjo4Vt8aw5s{{Kk#Ib?Ge0v9dpROghRQ@ln@ov= z!cfc=qf6N}Vfjh2GStdU%(z}My3#D|F6B}!LEWBG112{MK>p77tet6Z$VDy8%f%HR6#W+vu@LAN`un?4ow8t}tpcI*ja3e*37D>8)!1SxvIvMEA zXCVVkBlslH%vCgR@UBdrd{Oq<#$W|9ivuoB+DlQV#A4L0pZ2<3E|6%gXP1}_VBIdi zI@_+!vRNb;ak1bt%mFvw^0Uilm>U(j%X(tB3=-wlEyEoH@wvd(tykMkhAqhc&%6=e zT@|Dh>XmxPdERC)f{wXyaO2)K1Fx3v;zYrPzUSWc%xB?;|4h&Dfx!%{{(k98Zsk4J?!0oa zpFuA$Eevz!V69~k^*j>0zOOJpz2DL2ujVb^odRo~0*O%4N*AEX#Tk@f+BwzyD1lKw zA!*WG;_T>H`UJtY#JD2CmQXk}t=`7wbQEgJrbhOj4|bTv7GA2U#|4qPVX46&+!XEq zqmigjfY*^RcgEh^c^8}KhDpP2ekF55GDTyJMzFVd0{jx_tYRUG{+fn)iXN=Mmh0Rq zoXWdTn535T>_}(Dha+h;(uOaDGcH6*DSAN9Ep*2vI+k^*AbUN$L$ln0L!YQgi7&>y z;XWd$9MT9M6Z|{LBxfh~B=QlO-J9qEfex9$+Up`==gIj(_#XTj-R7U3vhorehxA%Mt>na z7`b@R&3S7uI<>#FB$8rgpUU-wmB+~UA9SP7=0=}lvqe2=fXV3AQ^u$kMSmFy#|?Pu z6V68G!r84~%Rmb!?piA=roz8MG9*=kG=@BXUu%-1OH7D0@fs?8;b4r{utKI1PN~jN zzLb|`YSrr^MVc{Q?ffhy?oLQNO%tiNHqZmiy?er;{$FNMKfSa_`>e4f;?*g7fRY<0 z9a>(JN6U!hp;ZZ1V?c$lnPQ-+opu+hGA7PVGnSWE(i3u^AOGH|p|Bhj^kQW$A;d0$ zR+!oZb9`X3AGOIRA|bDsC5VU4^rHMsPmPwEOE^fSnqG?`6qzb$Tsc%ron^)FR6V3B z59ny1CR_vwa(t$DmI}?CO0>w0bQbf>%kQ`tV4y^wpE$1c@k2x(!CifL9T9fKten+dU$M;E^`4 zjjVr5{t9Ouk!F654SbjIj7R0gw7$%Z$Lf^~)8N>T6%~s(;ffp~lm;p%&a=;1yd_kl zAa&RwXks;9ao3@0fASb-m$V%gVv^KN_ zW=c!dv>^#$A;FiE7O@+kG^xOZPZwQH_D$`^VnWVo@ZkgQbl0X%<+l z@Z3Ee7TAAUu0NwOS;6ymdSJ2ybboe_lEu@5=x#%F$=VGZ%YYv)yO*y12M03{GGXjX z<|O*mK_^iI;39hFw0EVGukNIi%VXukk+`b?%CFt)w*D{Wg&arjN_rZH15e$~gdizz zedlVbb{ zV;KXU*0%TPHFF@NhS_jnloh`AiUeOT25f@AJ1UH8FI|N#n-=N*S|WOzkQRk-`5X5; zEBR}d33J+mid1q>=~A^_{hWwJ%_zGS#2dR+sn@G^=P+VT>tKlOOc=-%rN+^Q?1i1n z83+r;tznPRq6|NqggqlwwZ6cC!4flQ5HWk`LN~310pBijiLr|y@$+zUCaC7yRdbG) zN(CX~$X1djxWu~$B-J_Af5n4t4}3a*rOXG8vg2`C$$b?Pe=DO{P#ums3}={>N-e{L z=qV$r;j3CG;A&Pvc?mWLRhn~cR=WG-aqe2PRI}=>G~XcRq0D(?CDarwf={+4X;0HE zI|Pdqm>#Lu5lcjxOLW;t=AFykqSOyq;(nUSDmCL%m>)FgZe(ZIs{A4kJbL+gL)Yxt0Lx)qvIP`xWx}wJ~SBJ^4ZK~AY5{v>Vt0A zfjQ39wf{aGXL?*}rZoVhAA0Dy)*1lzA3Su9S_6RliigiZYXD9FdLE4Y+K1hob2WIT zgmwyJf?}>1>jQqgncR32c@e@%qR#S-GwLNu4E^ng`;jP7bL~=kF#4uPoJ4tGMGl0q zT5LjPT9z6Ev`#8XI@@>Gd+#VGV^tEbO5C8RYpYSYjmvs)l))*hl{fwHTPfd~OS{y1*qSX@mPDswseyN(aLY9QYPrAJL`;V0ufhfF+Hg4MDxx3u9U zX2Sl<36Cr30p@Wm6_;ze;qq`zf_t&a1Ds}gjrk;@Kj6d^s$oowmurrXi`2Toe^pQJ z1N~J#Tih871!OdFfRd(EG4;Tbt)|%U)ff%o4f_J~0ZGWj+)s;kJ`N}2z=MpWLYe9j zY6~5<{(|>s#wbsJHn6#X?S1o!4VZo+usrpn9Ca$GwneHI~=Oi zID;1CK?r34`nw+Re;ah~jkH(yW28N!jn)KO%x1?E9RlsodJDAM)%3`d?c!3537mYQ z!=?D=%k^0FJ$7{|283&#R7!CTJjsYB+IaT{X3_A&Yv|ecg~1GzN-O#jld&rbC_8|dfR4YYe1sW{A~&gT~P(sDUg58`IBuqe8(S`Dy>RJB-$ zcl)?#VVpI58uxb4kappJk3_MKnSSH*PFa`nTXLeD3Li{ZT=M0NERX?<_P^v}&(j4j zt9q4y@adV^yUB8?R}E57(j;@OG<(lgQ|Jb4{ZDnjJiBbYxw!(HPklkR?=5uE;gY-Q z-VMHW^e<`zli?)6HW9++cU~_Zbr(^Wt=GyZx8gmbLA9(7yX6^y~7oIvt z<{sd#{o*+=_gCuZ82Q(~=;j=b&dfau24f24q)re-ucJ%)a(Xc4?>z0;!dvrf;T|90 z#m`f$j;!+Z7Khqw5`M8FrC9w%Yn;BUgcCNf z219Z}JNf=jhgTB%TjCs2la!u4xM+(r_vS+QZFDgE!f|t6C=Odr*|XxoNK(CEIdEij zO`p!MY0{FICw3dqME35s*B!^+aW)Zf7wts}A7T=<`_N&jHpHV7EoqRzaxFCJC@Oie z5EJZAEb(uBNsssY2P3|jl4xTzN?+iIuhTO&u-dbjJ9d)f1OLUdC@6%@4D(b0FYVj)UzrlOI&4Br%UcEaXC|p5Y6`Bj{*JvJ41{F&Juk4q35* zW`}4XMEVrZ;PftW$8mVD0yKODb8j9lo`}L-<9bTic1Lqg<}GH4rAh@7VC=&VAkrla z0rz2}vDa6fE^&4eUPNXF9KKtVq|PvKC$v4jNZa8(^k5rTo^e}wUv4W;WwsY@E~b5@ zR;gMLA9dAgV$6iAATVPBeFkk*ql0YmllqD*fwzDmWXqF2^XgVE7%c3OV@B>ECzD)Mem9&k)Y>4OLCjU^(<-!zCP&_`0GfDZ zL3}y^TSlo`4Tx4cuL&RBNSt`~n{+KbN)Pb(<3Tt7%3yZ>%HCMMuTz{t<}_WFwK>n} zR;)lVb8ev$P&4YWIK>%&gz(#plnCjOYPy?M{4sz;zGEd(3X+Ao48QqGx45g=U#!$X zW{EI|QyN?W896HnNqa4@yeWq$Yo02eZKjxrWBZtVdi;mCg`G4?Mf% z=QEt^wHe%@f^;A_EKARfF!Z*_@#BrP=DLH~?sDQYBNZ)ew>dF5@aE&f8rV}=V;=47 zt#qyJt#Qk;?=+oX6|aX?pK2FRy$FL>3;LaNp?Cj z@33zIjS@pEDQ?k#uY6uVQAGO78oWi!B9<+@ci)ooPHrj6QfjnNyGc02fF;YXRR(5g7UKI$g$y?q}T1Th?u4wJd)4EqV@L7>IC}?~G>< z*V(@SXQl`MithR_MO==xl3}8+(n}vwXcpGHyXWREcW?Kw!hB6DQ~bA3O`$_>lK=+^ zU9DuI0E3Ih^<3$6QRHK{e1etNMWV0=HXf%bXijIRm|Am&=9IXA;xRm;-zqzOX~W+PqwkMc-prV-6tv z+J#DM|BAS2T$dwvZshHWA71=C5|&0*XP{JS+m|H7`=zHb=dg~@hcTxIcGeF_kT+o6 zagF1ZKHb$&a#opPgoxBwjnrT67IS%QiJopa%dD%no3ql;Yf+_1+bhz+)MkRW!vrh9 z4`v2jNi8V4z31lI^-5CC4$qEgm)hmo3@tUim)QG+nMIWRHGz*SCM0FU5DsH4&894HuUhq{zh@M2mcvQgqyxq?=j|%9=cb_AV3UD9ZeGWXTxp-mZ zKk{>4#>MN0^v37u!EjhnwLd*PkQ?)?v#cDuM|`FH>Af4H1M~%cxS5{Xfq;d-VrP6U zVS6Dt3nt#IFhDCh?86Fk1-7yc6n!lc$9X`sWv}BlUf-LI*Rs$RWPT}w!E8F;l9Cw0 zSuLQFFKwDqA?EZO(!%(Bc8F%SsEdt;od&oc8>W>mBupWhIL`|B-5C9y;&=m|4hXq_ zujB7t+mpXjY_P!Jn>#Lu|5ceDVCqHtT+dJS>^aLhD%i1@Sxc4$5dwoEhY&!U%vZC} zwn1iU(Q)(J1*yC{M-Qg?0T0mUdjmw=vw^`5a;)QE;#93B)r>zD+Zn)a>mrzV5ESph zujr->yKlj#1_5$@?%`QBHHd(dFDtBH7yNQ!emCy#V>#`Pvb|GcGQfL^4b`%fsOL%I z5r)7gP|xohbDMuU=h^PXJQh3WP{LrL-C!zF^2%Uy6V+7HwcFSb&RNv#jy5!J);U)z zi+Jq_jA^Cd?t46(L;cAm^vtIBCr=CKUZ&SH^PT<7kkH-?PF+b;XNPn?az+qP}&@rFH) zz;&!ra-F+$?#M2bo#Xy|-g2o);8X_(3qbzFb2iG*!#=wji2&t~4(JW`sr31xbW%4JhYzO5QraCXq1gg(Qq=Um!x%(5~wm#44r^7HSsEl~7IM zKjLvY+Y$s1BRnpNeTC&n36XR*Hi!d5>avbiUNz}fXH9N(_M}4n5T(Y31WD3i^Q!nb zVPopVdITpuy-)lVCl`xm9#G0|%}s%4GsvX#^c#VTZr~PgY4|FBchw+3LWOKf94{Kq zE*ZHT8uo;?>_X6FSr}?{6vT!|U81u;CB%G$9&F)_$DKSox12m{!BNy9OzTUTxU+CJ z1X-n4;iScp?9Is7z5HPyXuJVLGKuo`4PP(`xGBy7OS;G5XMT#4s&JpDC6Ns-;xl}( zF)(M4gYVL2`7ZtetfW1c3S^^ zE6!%P`Q&IHqj}G*;4s7U5jmUK(~>KR>&=mH9$v{)#Rf{-iAzaqXeXBgD0AU2tCDNu zOOkWtZM`F<2!2`Cos+LCDU1EF*Hh0SzY^JNGe+Dpmvahd$E=)G!y)Xwi;($dda!iw zzsDi;d&?j+UTCE4dML6o%Nwx9XTWEPE`3H^vpuWAZ?N5XnQEz#Ig?#0mXM0KytPpX z3UMaKs#%=PRO94dqR`v&qOYUKC9xqaX;id`%gi5yls(P4o-D~0vizH|CalO7V^Wb? z5a;umspKvw!Wp=&RFxEI7V?5JZIF?%*N@!mmggnCtz2V4?F*@Jl!$3$6LyT|K85Pw73CDtJvOb`}`hXIB$yHhUoI=KIVUYfZ#j zqK~b=fD=pNhxgO-k+){}?4swh`_qN?;sOoa{#*x`*C)F+CXW1^2rlUzrRt zW7}}N9k=8T_EA!=z+vzMEEQ@lf`Vv9;K7Os-}0cFbTK<=OBJWLt;-en-y)GLFxe{} zauc4*Pk3JiuGg?Ebta8-YT6@iFQjVl;#z|=UX^cJc7YOZ!zsm7o4-40umgw`KeKwI zDc6p{FoY5Gp&W^hxGQ$qOKNnVVJ$gtNI`PhzK9-Rr2UY?%8o2nMvv7?HI9~b-zkArB<&*iSnVBOU+3R2$kQ~;=CkF{+jQvMiyjqz^-KNq!6!Y_y zMl(DM(92f1UX3kSx|pyR=n(A(K29oQ5W+)MYHT<=4cQk`BFus8ySsKPv3N@MYr zPL4rQVCxeA5vm|m9&v;_tcZmkQ85ed-xAfGTBi_nkPgOT!?R_bxkM5>@7VN&-NL^9 zB%%Cm^kDUH0jjL`vYc^ZKSFAf+&aQg+7{s^0s19xho@V_O36WTLH2G(fo67g$Hx~V@{J~9eiOWU*cDQ%4j zg2xLrx4gYG;mhBkL;Ep$&}z-++^$*3X$THs>o$3bX)f4!bYK_g)U@rUCv4jv+(yJdPKr+rgIg(70c;d+b2$&udr?i#P5=6ZE?vE4^l== zPi1QDCwEaolxS4ugwd_k=BjO$(d=ioCddd*55Whq-AslV&S4d_hamxCT6MaJi4+e9 zW;`U=qc3S|G^L8!mJ}J_;9Zf{D~S`g4LX+>UG!m!A|ChX5#{8jgIzP6 ztQ#!K#4Gcmm}H8L@CQ#`ph9+|i)J}@@1XE+|c@zB)h^mIHq z6^|V}G(I*;-;GV|9zVQiY+_%0Ew!7NoQcQB4vx)Gr!$i=2Gp*`MyJu)!O^MR`{|z} z*N%;k&D=B`?;V?&K%aZ5(~y}M``#y)a}IB#NH_yW%S_a z#0*_V6ZBm?dOiIkp58w)KF&jp946?e7{1+;hi;l0+qZuv-ak3MXOzCYc9b9+xpsV1 zhN4OB9v>MyI2`X8IXJR!lv_w?w(m0JZAj>_-95G^ith`XY~RVOZXl^e?>QO1u%n~TP$X0uHb+n~ z^GHla^xG>}1nn>186U3ERi>|O<^X?<7>>Ske1)4mK{AoFq95JmTXQ-F`qG<;K6^6! zwJ5&^qU{e>t#lm{+}cT`QCx>jiP@e==_zd zR=Livq=i1pwGpFqjcLqQBY@)Hdb{f%=Od z`P7NbD@FfGFz!`%1^om6X*G?$eP7U$D>>k6-}4OvtHa-m`g_pr|6JoeiMAmJ8@O`X zfv+d~nHQ{K*z?!}LCYNbxRYtWWY7{2y>-+m(Vdr^N6y8Z3DgKp`J?Sto5bkBW3J3eCkz3=#f z6>Gy6iuOX#^Xb90zGpgMhmwV6v~Nw&j*l0<_WizNUFP?q{vLGuPj?30($U(Jl6;jm zOVOow2Tl2K*-yUvSKga>rx?5w3^8?oFvL}$qH;WIz=yR=^L{ zR$R|v-7XYSaBX{(TtOo7;GG^t6_8ig4WX&Um-!5@eqICy0vQ-x=bfo{k+LlKxic9f zG8MUDUH&p8fN{;b{C7Xj1q`Ib4|O45hJ=Oc%^$l8r!`Oo>!`Old? zf3pU%KW_hlGrfBLbN+MwbN+MwbN+Mw^Z&_b%c>~4j2@T^Rz<7cvZLEeFc1tx>*#L} zu3X2~hC5&z8NG2PdOm%5$L^UMCl8Jsihg}9{bMiv5?zPC9k}7znW@py=*8>!AA3e- zMxuik^WX9Ik6%K6oxW*$X7pgR?xpninaM+AyQAAL#b0N}rR|O1JkOV$|D6B)Kl1s% DtBO+i literal 0 HcwPel00001 diff --git a/puzzles.txt b/puzzles.txt new file mode 100644 index 0000000..6eca604 --- /dev/null +++ b/puzzles.txt @@ -0,0 +1,1943 @@ + Simon Tatham's Portable Puzzle Collection + ========================================= + +This is a collection of small one-player puzzle games. + +This manual is copyright 2004-5 Simon Tatham. All rights reserved. You may +distribute this documentation under the MIT licence. See appendix A for the +licence text in full. + +Chapter 1: Introduction +----------------------- + + I wrote this collection because I thought there should be more small + desktop toys available: little games you can pop up in a window and + play for two or three minutes while you take a break from whatever + else you were doing. And I was also annoyed that every time I found + a good game on (say) Unix, it wasn't available the next time I was + sitting at a Windows machine, or vice versa; so I arranged that + everything in my personal puzzle collection will happily run on + both, and have more recently done a port to Mac OS X as well. When I + find (or perhaps invent) further puzzle games that I like, they'll + be added to this collection and will immediately be available on + both platforms. And if anyone feels like writing any other front + ends - PocketPC, Mac OS pre-10, or whatever it might be - then all + the games in this framework will immediately become available on + another platform as well. + + The actual games in this collection were mostly not my invention; + they are re-implementations of existing game concepts within my + portable puzzle framework. I do not claim credit, in general, for + inventing the rules of any of these puzzles. (I don't even claim + authorship of all the code; some of the puzzles have been submitted + by other authors.) + + This collection is distributed under the MIT licence (see appendix + A). This means that you can do pretty much anything you like with + the game binaries or the code, except pretending you wrote them + yourself, or suing me if anything goes wrong. + + The most recent versions, and source code, can be found at + http://www.chiark.greenend.org.uk/~sgtatham/puzzles/. + + Please report bugs to anakin@pobox.com. You might find it helpful to + read this article before reporting a bug: + + http://www.chiark.greenend.org.uk/~sgtatham/bugs.html + + Patches are welcome. Especially if they provide a new front end (to + make all these games run on another platform), or a new game. + +Chapter 2: Common features +-------------------------- + + This chapter describes features that are common to all the games. + + 2.1 Common actions + + These actions are all available from the `Game' menu and via + keyboard shortcuts, in addition to any game-specific actions. + + (On Mac OS X, to conform with local user interface standards, these + actions are situated on the `File' and `Edit' menus instead.) + + _New game_ (`N', Ctrl+`N') + + Starts a new game, with a random initial state. + + _Restart game_ + + Resets the current game to its initial state. (This can be + undone.) + + _Load_ + + Loads a saved game from a file on disk. + + _Save_ + + Saves the current state of your game to a file on disk. + + The Load and Save operations should preserve your entire game + history (so you can save, reload, and still Undo and Redo things + you had done before saving). + + _Print_ + + Where supported (currently only on Windows), brings up a dialog + allowing you to print an arbitrary number of puzzles randomly + generated from the current parameters, optionally including + the current puzzle. (Only for puzzles which make sense to + print, of course - it's hard to think of a sensible printable + representation of Fifteen!) + + _Undo_ (`U', Ctrl+`Z', Ctrl+`_') + + Undoes a single move. (You can undo moves back to the start of + the session.) + + _Redo_ (`R', Ctrl+`R') + + Redoes a previously undone move. + + _Copy_ + + Copies the current state of your game to the clipboard in text + format, so that you can paste it into (say) an e-mail client or + a web message board if you're discussing the game with someone + else. (Not all games support this feature.) + + _Solve_ + + Transforms the puzzle instantly into its solved state. For some + games (Cube) this feature is not supported at all because it is + of no particular use. For other games (such as Pattern), the + solved state can be used to give you information, if you can't + see how a solution can exist at all or you want to know where + you made a mistake. For still other games (such as Sixteen), + automatic solution tells you nothing about how to _get_ to + the solution, but it does provide a useful way to get there + quickly so that you can experiment with set-piece moves and + transformations. + + Some games (such as Solo) are capable of solving a game ID you + have typed in from elsewhere. Other games (such as Rectangles) + cannot solve a game ID they didn't invent themself, but when + they did invent the game ID they know what the solution is + already. Still other games (Pattern) can solve _some_ external + game IDs, but only if they aren't too difficult. + + The `Solve' command adds the solved state to the end of the undo + chain for the puzzle. In other words, if you want to go back to + solving it yourself after seeing the answer, you can just press + Undo. + + _Quit_ (`Q', Ctrl+`Q') + + Closes the application entirely. + + 2.2 Specifying games with the game ID + + There are two ways to save a game specification out of a puzzle and + recreate it later, or recreate it in somebody else's copy of the + same puzzle. + + The `Specific' and `Random Seed' options from the `Game' menu (or + the `File' menu, on Mac OS X) each show a piece of text (a `game + ID') which is sufficient to reconstruct precisely the same game at a + later date. + + You can enter either of these pieces of text back into the program + (via the same `Specific' or `Random Seed' menu options) at a later + point, and it will recreate the same game. You can also use either + one as a command line argument (on Windows or Unix); see section 2.4 + for more detail. + + The difference between the two forms is that a descriptive game ID + is a literal _description_ of the initial state of the game, whereas + a random seed is just a piece of arbitrary text which was provided + as input to the random number generator used to create the puzzle. + This means that: + + - Descriptive game IDs tend to be longer in many puzzles + (although some, such as Cube (chapter 4), only need very short + descriptions). So a random seed is often a _quicker_ way to + note down the puzzle you're currently playing, or to tell it to + somebody else so they can play the same one as you. + + - Any text at all is a valid random seed. The automatically + generated ones are fifteen-digit numbers, but anything will do; + you can type in your full name, or a word you just made up, and + a valid puzzle will be generated from it. This provides a way + for two or more people to race to complete the same puzzle: + you think of a random seed, then everybody types it in at the + same time, and nobody has an advantage due to having seen the + generated puzzle before anybody else. + + - It is often possible to convert puzzles from other sources (such + as `nonograms' or `sudoku' from newspapers) into descriptive + game IDs suitable for use with these programs. + + - Random seeds are not guaranteed to produce the same result + if you use them with a different _version_ of the puzzle + program. This is because the generation algorithm might have + been improved or modified in later versions of the code, and + will therefore produce a different result when given the same + sequence of random numbers. Use a descriptive game ID if you + aren't sure that it will be used on the same version of the + program as yours. + + (Use the `About' menu option to find out the version number of + the program. Programs with the same version number running on + different platforms should still be random-seed compatible.) + + A descriptive game ID starts with a piece of text which encodes the + _parameters_ of the current game (such as grid size). Then there is + a colon, and after that is the description of the game's initial + state. A random seed starts with a similar string of parameters, but + then it contains a hash sign followed by arbitrary data. + + If you enter a descriptive game ID, the program will not be able + to show you the random seed which generated it, since it wasn't + generated _from_ a random seed. If you _enter_ a random seed, + however, the program will be able to show you the descriptive game + ID derived from that random seed. + + Note that the game parameter strings are not always identical + between the two forms. For some games, there will be parameter + data provided with the random seed which is not included in the + descriptive game ID. This is because that parameter information is + only relevant when _generating_ puzzle grids, and is not important + when playing them. Thus, for example, the difficulty level in Solo + (chapter 11) is not mentioned in the descriptive game ID. + + These additional parameters are also not set permanently if you type + in a game ID. For example, suppose you have Solo set to `Advanced' + difficulty level, and then a friend wants your help with a `Trivial' + puzzle; so the friend reads out a random seed specifying `Trivial' + difficulty, and you type it in. The program will generate you the + same `Trivial' grid which your friend was having trouble with, but + once you have finished playing it, when you ask for a new game it + will automatically go back to the `Advanced' difficulty which it was + previously set on. + + 2.3 The `Type' menu + + The `Type' menu, if present, may contain a list of preset game + settings. Selecting one of these will start a new random game with + the parameters specified. + + The `Type' menu may also contain a `Custom' option which allows you + to fine-tune game parameters. The parameters available are specific + to each game and are described in the following sections. + + 2.4 Specifying game parameters on the command line + + (This section does not apply to the Mac OS X version.) + + The games in this collection deliberately do not ever save + information on to the computer they run on: they have no high score + tables and no saved preferences. (This is because I expect at least + some people to play them at work, and those people will probably + appreciate leaving as little evidence as possible!) + + However, if you do want to arrange for one of these games to default + to a particular set of parameters, you can specify them on the + command line. + + The easiest way to do this is to set up the parameters you want + using the `Type' menu (see section 2.3), and then to select `Random + Seed' from the `Game' or `File' menu (see section 2.2). The text + in the `Game ID' box will be composed of two parts, separated by a + hash. The first of these parts represents the game parameters (the + size of the playing area, for example, and anything else you set + using the `Type' menu). + + If you run the game with just that parameter text on the command + line, it will start up with the settings you specified. + + For example: if you run Cube (see chapter 4), select `Octahedron' + from the `Type' menu, and then go to the game ID selection, you + will see a string of the form `o2x2#338686542711620'. Take only the + part before the hash (`o2x2'), and start Cube with that text on the + command line: `cube o2x2'. + + If you copy the _entire_ game ID on to the command line, the game + will start up in the specific game that was described. This is + occasionally a more convenient way to start a particular game ID + than by pasting it into the game ID selection box. + + (You could also retrieve the encoded game parameters using the + `Specific' menu option instead of `Random Seed', but if you do then + some options, such as the difficulty level in Solo, will be missing. + See section 2.2 for more details on this.) + + 2.5 Unix command-line options + + (This section only applies to the Unix port.) + + In addition to specifying game parameters on the command line (see + section 2.4), you can also specify various options: + + --generate _n_ + + If this option is specified, instead of a puzzle being + displayed, a number of descriptive game IDs will be invented and + printed on standard output. This is useful for gaining access + to the game generation algorithms without necessarily using the + frontend. + + If game parameters are specified on the command-line, they will + be used to generate the game IDs; otherwise a default set of + parameters will be used. + + The most common use of this option is in conjunction with `-- + print', in which case its behaviour is slightly different; see + below. + + --print _w_x_h_ + + If this option is specified, instead of a puzzle being + displayed, a printed representation of one or more unsolved + puzzles is sent to standard output, in PostScript format. + + On each page of puzzles, there will be _w_ across and _h_ down. + If there are more puzzles than _w_x_h_, more than one page will + be printed. + + If `--generate' has also been specified, the invented game + IDs will be used to generate the printed output. Otherwise, + a list of game IDs is expected on standard input (which can + be descriptive or random seeds; see section 2.2), in the same + format produced by `--generate'. + + For example: + + net --generate 12 --print 2x3 7x7w | lpr + + will generate two pages of printed Net puzzles (each of which + will have a 7x7 wrapping grid), and pipe the output to the `lpr' + command, which on many systems will send them to an actual + printer. + + There are various other options which affect printing; see + below. + + --version + + Prints version information about the game, and then quits. + + The following options are only meaningful if `--print' is also + specified: + + --with-solutions + + The set of pages filled with unsolved puzzles will be followed + by the solutions to those puzzles. + + --scale _n_ + + Adjusts how big each puzzle is when printed. Larger numbers make + puzzles bigger; the default is 1.0. + + --colour + + Puzzles will be printed in colour, rather than in black and + white (if supported by the puzzle). + +Chapter 3: Net +-------------- + + (_Note:_ the Windows version of this game is called NETGAME.EXE to + avoid clashing with Windows's own NET.EXE.) + + I originally saw this in the form of a Flash game called FreeNet [1] + , written by Pavils Jurjans; there are several other implementations + under the name NetWalk. The computer prepares a network by + connecting up the centres of squares in a grid, and then shuffles + the network by rotating every tile randomly. Your job is to rotate + it all back into place. The successful solution will be an entirely + connected network, with no closed loops. As a visual aid, all tiles + which are connected to the one in the middle are highlighted. + + [1] http://www.jurjans.lv/stuff/net/FreeNet.htm + + 3.1 Net controls + + This game can be played with either the keyboard or the mouse. The + controls are: + + _Select tile_: mouse pointer, arrow keys + + _Rotate tile anticlockwise_: left mouse button, `A' key + + _Rotate tile clockwise_: right mouse button, `D' key + + _Rotate tile by 180 degrees_: `F' key + + _Lock (or unlock) tile_: middle mouse button, shift-click, `S' key + + You can lock a tile once you're sure of its orientation. You + can also unlock it again, but while it's locked you can't + accidentally turn it. + + The following controls are not necessary to complete the game, but + may be useful: + + _Shift grid_: Shift + arrow keys + + On grids that wrap, you can move the origin of the grid, so + that tiles that were on opposite sides of the grid can be seen + together. + + _Move centre_: Ctrl + arrow keys + + You can change which tile is used as the source of highlighting. + (It doesn't ultimately matter which tile this is, as every tile + will be connected to every other tile in a correct solution, + but it may be helpful in the intermediate stages of solving the + puzzle.) + + _Jumble tiles_: `J' key + + This key turns all tiles that are not locked to random + orientations. + + (All the actions described in section 2.1 are also available.) + + 3.2 Net parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. + + _Width_, _Height_ + + Size of grid in tiles. + + _Walls wrap around_ + + If checked, flow can pass from the left edge to the right edge, + and from top to bottom, and vice versa. + + _Barrier probability_ + + A number between 0.0 and 1.0 controlling whether an immovable + barrier is placed between two tiles to prevent flow between + them (a higher number gives more barriers). Since barriers + are immovable, they act as constraints on the solution (i.e., + hints). + + The grid generation in Net has been carefully arranged so that + the barriers are independent of the rest of the grid. This + means that if you note down the random seed used to generate + the current puzzle (see section 2.2), change the _Barrier + probability_ parameter, and then re-enter the same random seed, + you should see exactly the same starting grid, with the only + change being the number of barriers. So if you're stuck on a + particular grid and need a hint, you could start up another + instance of Net, set up the same parameters but a higher barrier + probability, and enter the game seed from the original Net + window. + + _Ensure unique solution_ + + Normally, Net will make sure that the puzzles it presents have + only one solution. Puzzles with ambiguous sections can be more + difficult and more subtle, so if you like you can turn off this + feature and risk having ambiguous puzzles. (Also, finding _all_ + the possible solutions can be an additional challenge for an + advanced player.) + +Chapter 4: Cube +--------------- + + This is another one I originally saw as a web game. This one was a + Java game [2], by Paul Scott. You have a grid of 16 squares, six of + which are blue; on one square rests a cube. Your move is to use the + arrow keys to roll the cube through 90 degrees so that it moves to + an adjacent square. If you roll the cube on to a blue square, the + blue square is picked up on one face of the cube; if you roll a blue + face of the cube on to a non-blue square, the blueness is put down + again. (In general, whenever you roll the cube, the two faces that + come into contact swap colours.) Your job is to get all six blue + squares on to the six faces of the cube at the same time. Count your + moves and try to do it in as few as possible. + + Unlike the original Java game, my version has an additional feature: + once you've mastered the game with a cube rolling on a square grid, + you can change to a triangular grid and roll any of a tetrahedron, + an octahedron or an icosahedron. + + [2] http://www3.sympatico.ca/paulscott/cube/cube.htm + + 4.1 Cube controls + + This game can be played with either the keyboard or the mouse. + + Left-clicking anywhere on the window will move the cube (or other + solid) towards the mouse pointer. + + The arrow keys can also used to roll the cube on its square grid in + the four cardinal directions. On the triangular grids, the mapping + of arrow keys to directions is more approximate. Vertical movement + is disallowed where it doesn't make sense. The four keys surrounding + the arrow keys on the numeric keypad (`7', `9', `1', `3') can be + used for diagonal movement. + + (All the actions described in section 2.1 are also available.) + + 4.2 Cube parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. + + _Type of solid_ + + Selects the solid to roll (and hence the shape of the grid): + tetrahedron, cube, octahedron, or icosahedron. + + _Width / top_, _Height / bottom_ + + On a square grid, horizontal and vertical dimensions. On a + triangular grid, the number of triangles on the top and bottom + rows respectively. + +Chapter 5: Fifteen +------------------ + + The old ones are the best: this is the good old `15-puzzle' with + sliding tiles. You have a 4x4 square grid; 15 squares contain + numbered tiles, and the sixteenth is empty. Your move is to choose a + tile next to the empty space, and slide it into the space. The aim + is to end up with the tiles in numerical order, with the space in + the bottom right (so that the top row reads 1,2,3,4 and the bottom + row reads 13,14,15,_space_). + + 5.1 Fifteen controls + + This game can be controlled with the mouse or the keyboard. + + A left-click with the mouse in the row or column containing the + empty space will move as many tiles as necessary to move the space + to the mouse pointer. + + The arrow keys will move a tile adjacent to the space in the + direction indicated (moving the space in the _opposite_ direction). + + (All the actions described in section 2.1 are also available.) + + 5.2 Fifteen parameters + + The only options available from the `Custom...' option on the `Type' + menu are _Width_ and _Height_, which are self-explanatory. (Once + you've changed these, it's not a `15-puzzle' any more, of course!) + +Chapter 6: Sixteen +------------------ + + Another sliding tile puzzle, visually similar to Fifteen (see + chapter 5) but with a different type of move. This time, there is no + hole: all 16 squares on the grid contain numbered squares. Your move + is to shift an entire row left or right, or shift an entire column + up or down; every time you do that, the tile you shift off the grid + re-appears at the other end of the same row, in the space you just + vacated. To win, arrange the tiles into numerical order (1,2,3,4 on + the top row, 13,14,15,16 on the bottom). When you've done that, try + playing on different sizes of grid. + + I _might_ have invented this game myself, though only by accident + if so (and I'm sure other people have independently invented it). I + thought I was imitating a screensaver I'd seen, but I have a feeling + that the screensaver might actually have been a Fifteen-type puzzle + rather than this slightly different kind. So this might be the one + thing in my puzzle collection which represents creativity on my part + rather than just engineering. + + 6.1 Sixteen controls + + This game is played with the mouse. Left-clicking on an arrow will + move the appropriate row or column in the direction indicated. + Right-clicking will move it in the opposite direction. + + (All the actions described in section 2.1 are also available.) + + 6.2 Sixteen parameters + + The parameters available from the `Custom...' option on the `Type' + menu are: + + - _Width_ and _Height_, which are self-explanatory. + + - You can ask for a limited shuffling operation to be performed on + the grid. By default, Sixteen will shuffle the grid in such a + way that any arrangement is about as probable as any other. You + can override this by requesting a precise number of shuffling + moves to be performed. Typically your aim is then to determine + the precise set of shuffling moves and invert them exactly, + so that you answer (say) a four-move shuffle with a four-move + solution. Note that the more moves you ask for, the more likely + it is that solutions shorter than the target length will turn + out to be possible. + +Chapter 7: Twiddle +------------------ + + Twiddle is a tile-rearrangement puzzle, visually similar to Sixteen + (see chapter 6): you are given a grid of square tiles, each + containing a number, and your aim is to arrange the numbers into + ascending order. + + In basic Twiddle, your move is to rotate a square group of four + tiles about their common centre. (Orientation is not significant + in the basic puzzle, although you can select it.) On more advanced + settings, you can rotate a larger square group of tiles. + + I first saw this type of puzzle in the GameCube game `Metroid + Prime 2'. In the Main Gyro Chamber in that game, there is a puzzle + you solve to unlock a door, which is a special case of Twiddle. I + developed this game as a generalisation of that puzzle. + + 7.1 Twiddle controls + + To play Twiddle, click the mouse in the centre of the square group + you wish to rotate. In the basic mode, you rotate a 2x2 square, + which means you have to click at a corner point where four tiles + meet. + + In more advanced modes you might be rotating 3x3 or even more at a + time; if the size of the square is odd then you simply click in the + centre tile of the square you want to rotate. + + Clicking with the left mouse button rotates the group anticlockwise. + Clicking with the right button rotates it clockwise. + + (All the actions described in section 2.1 are also available.) + + 7.2 Twiddle parameters + + Twiddle provides several configuration options via the `Custom' + option on the `Type' menu: + + - You can configure the width and height of the puzzle grid. + + - You can configure the size of square block that rotates at a + time. + + - You can ask for every square in the grid to be distinguishable + (the default), or you can ask for a simplified puzzle in which + there are groups of identical numbers. In the simplified puzzle + your aim is just to arrange all the 1s into the first row, all + the 2s into the second row, and so on. + + - You can configure whether the orientation of tiles matters. If + you ask for an orientable puzzle, each tile will have a triangle + drawn in it. All the triangles must be pointing upwards to + complete the puzzle. + + - You can ask for a limited shuffling operation to be performed + on the grid. By default, Twiddle will shuffle the grid so much + that any arrangement is about as probable as any other. You can + override this by requesting a precise number of shuffling moves + to be performed. Typically your aim is then to determine the + precise set of shuffling moves and invert them exactly, so that + you answer (say) a four-move shuffle with a four-move solution. + Note that the more moves you ask for, the more likely it is that + solutions shorter than the target length will turn out to be + possible. + +Chapter 8: Rectangles +--------------------- + + You have a grid of squares, with numbers written in some (but + not all) of the squares. Your task is to subdivide the grid into + rectangles of various sizes, such that (a) every rectangle contains + exactly one numbered square, and (b) the area of each rectangle is + equal to the number written in its numbered square. + + Credit for this game goes to the Japanese puzzle magazine Nikoli + [3]; I've also seen a Palm implementation at Puzzle Palace [4]. + Unlike Puzzle Palace's implementation, my version automatically + generates random grids of any size you like. The quality of puzzle + design is therefore not quite as good as hand-crafted puzzles would + be, but on the plus side you get an inexhaustible supply of puzzles + tailored to your own specification. + + [3] http://www.nikoli.co.jp/puzzles/7/index_text-e.htm + + [4] http://www.puzzle.gr.jp/puzzle/sikaku/palm/index.html.en + + 8.1 Rectangles controls + + This game is played with the mouse. + + Left-click any edge to toggle it on or off, or click and drag to + draw an entire rectangle (or line) on the grid in one go (removing + any existing edges within that rectangle). + + When a rectangle of the correct size is completed, it will be + shaded. + + (All the actions described in section 2.1 are also available.) + + 8.2 Rectangles parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. + + _Width_, _Height_ + + Size of grid, in squares. + + _Expansion factor_ + + This is a mechanism for changing the type of grids generated by + the program. Some people prefer a grid containing a few large + rectangles to one containing many small ones. So you can ask + Rectangles to essentially generate a _smaller_ grid than the + size you specified, and then to expand it by adding rows and + columns. + + The default expansion factor of zero means that Rectangles will + simply generate a grid of the size you ask for, and do nothing + further. If you set an expansion factor of (say) 0.5, it means + that each dimension of the grid will be expanded to half again + as big after generation. In other words, the initial grid will + be 2/3 the size in each dimension, and will be expanded to its + full size without adding any more rectangles. + + Setting an expansion factor of around 0.5 tends to make the + game more difficult, and also (in my experience) rewards a + less deductive and more intuitive playing style. If you set it + _too_ high, though, the game simply cannot generate more than a + few rectangles to cover the entire grid, and the game becomes + trivial. + + _Ensure unique solution_ + + Normally, Rectangles will make sure that the puzzles it presents + have only one solution. Puzzles with ambiguous sections can be + more difficult and more subtle, so if you like you can turn off + this feature and risk having ambiguous puzzles. Also, finding + _all_ the possible solutions can be an additional challenge for + an advanced player. Turning off this option can also speed up + puzzle generation. + +Chapter 9: Netslide +------------------- + + This game combines the grid generation of Net (see chapter 3) with + the movement of Sixteen (see chapter 6): you have a Net grid, but + instead of rotating tiles back into place you have to slide them + into place by moving a whole row at a time. + + As in Sixteen, control is with the mouse. See section 6.1. + + The available game parameters have similar meanings to those in Net + (see section 3.2) and Sixteen (see section 6.2). + + Netslide was contributed to this collection by Richard Boulton. + +Chapter 10: Pattern +------------------- + + You have a grid of squares, which must all be filled in either black + or white. Beside each row of the grid are listed the lengths of the + runs of black squares on that row; above each column are listed the + lengths of the runs of black squares in that column. Your aim is to + fill in the entire grid black or white. + + I first saw this puzzle form around 1995, under the name + `nonograms'. I've seen it in various places since then, under + different names. + + Normally, puzzles of this type turn out to be a meaningful picture + of something once you've solved them. However, since this version + generates the puzzles automatically, they will just look like random + groupings of squares. (One user has suggested that this is actually + a _good_ thing, since it prevents you from guessing the colour of + squares based on the picture, and forces you to use logic instead.) + The advantage, though, is that you never run out of them. + + 10.1 Pattern controls + + This game is played with the mouse. + + Left-click in a square to colour it black. Right-click to colour it + white. If you make a mistake, you can middle-click, or hold down + Shift while clicking with any button, to colour the square in the + default grey (meaning `undecided') again. + + You can click and drag with the left or right mouse button to colour + a vertical or horizontal line of squares black or white at a time + (respectively). If you click and drag with the middle button, or + with Shift held down, you can colour a whole rectangle of squares + grey. + + (All the actions described in section 2.1 are also available.) + + 10.2 Pattern parameters + + The only options available from the `Custom...' option on the `Type' + menu are _Width_ and _Height_, which are self-explanatory. + +Chapter 11: Solo +---------------- + + You have a square grid, which is divided into square or rectangular + blocks. Each square must be filled in with a digit from 1 to the + size of the grid, in such a way that + + - every row contains only one occurrence of each digit + + - every column contains only one occurrence of each digit + + - every block contains only one occurrence of each digit. + + You are given some of the numbers as clues; your aim is to place the + rest of the numbers correctly. + + The default puzzle size is 3x3 (a 9x9 actual grid, divided into + nine 3x3 blocks). You can also select sizes with rectangular blocks + instead of square ones, such as 2x3 (a 6x6 grid divided into six 3x2 + blocks). + + If you select a puzzle size which requires more than 9 digits, the + additional digits will be letters of the alphabet. For example, if + you select 3x4 then the digits which go in your grid will be 1 to 9, + plus `a', `b' and `c'. + + I first saw this puzzle in Nikoli [5], although it's also been + popularised by various newspapers under the name `Sudoku' or `Su + Doku'. + + [5] http://www.nikoli.co.jp/puzzles/1/index_text-e.htm + + 11.1 Solo controls + + To play Solo, simply click the mouse in any empty square and then + type a digit or letter on the keyboard to fill that square. If you + make a mistake, click the mouse in the incorrect square and press + Space to clear it again (or use the Undo feature). + + If you _right_-click in a square and then type a number, that number + will be entered in the square as a `pencil mark'. You can have + pencil marks for multiple numbers in the same square. + + The game pays no attention to pencil marks, so exactly what you + use them for is up to you: you can use them as reminders that a + particular square needs to be re-examined once you know more about + a particular number, or you can use them as lists of the possible + numbers in a given square, or anything else you feel like. + + To erase a single pencil mark, right-click in the square and type + the same number again. + + All pencil marks in a square are erased when you left-click and type + a number, or when you left-click and press space. Right-clicking and + pressing space will also erase pencil marks. + + (All the actions described in section 2.1 are also available.) + + 11.2 Solo parameters + + Solo allows you to configure two separate dimensions of the puzzle + grid on the `Type' menu: the number of columns, and the number of + rows, into which the main grid is divided. (The size of a block is + the inverse of this: for example, if you select 2 columns and 3 + rows, each actual block will have 3 columns and 2 rows.) + + You can also configure the type of symmetry shown in the generated + puzzles. More symmetry makes the puzzles look prettier but may also + make them easier, since the symmetry constraints can force more + clues than necessary to be present. Completely asymmetric puzzles + have the freedom to contain as few clues as possible. + + Finally, you can configure the difficulty of the generated puzzles. + Difficulty levels are judged by the complexity of the techniques + of deduction required to solve the puzzle: each level requires a + mode of reasoning which was not necessary in the previous one. In + particular, on difficulty levels `Trivial' and `Basic' there will be + a square you can fill in with a single number at all times, whereas + at `Intermediate' level and beyond you will have to make partial + deductions about the _set_ of squares a number could be in (or the + set of numbers that could be in a square). At `Unreasonable' level, + even this is not enough, and you will eventually have to make a + guess, and then backtrack if it turns out to be wrong. + + Generating difficult puzzles is itself difficult: if you select one + of the higher difficulty levels, Solo may have to make many attempts + at generating a puzzle before it finds one hard enough for you. Be + prepared to wait, especially if you have also configured a large + puzzle size. + +Chapter 12: Mines +----------------- + + You have a grid of covered squares, some of which contain mines, but + you don't know which. Your job is to uncover every square which does + _not_ contain a mine. If you uncover a square containing a mine, you + lose. If you uncover a square which does not contain a mine, you + are told how many mines are contained within the eight surrounding + squares. + + This game needs no introduction; popularised by Windows, it is + perhaps the single best known desktop puzzle game in existence. + + This version of it has an unusual property. By default, it will + generate its mine positions in such a way as to ensure that you + never need to _guess_ where a mine is: you will always be able + to deduce it somehow. So you will never, as can happen in other + versions, get to the last four squares and discover that there are + two mines left but you have no way of knowing for sure where they + are. + + 12.1 Mines controls + + This game is played with the mouse. + + If you left-click in a covered square, it will be uncovered. + + If you right-click in a covered square, it will place a flag which + indicates that the square is believed to be a mine. Left-clicking in + a marked square will not uncover it, for safety. You can right-click + again to remove a mark placed in error. + + If you left-click in an _uncovered_ square, it will `clear around' + the square. This means: if the square has exactly as many flags + surrounding it as it should have mines, then all the covered squares + next to it which are _not_ flagged will be uncovered. So once you + think you know the location of all the mines around a square, you + can use this function as a shortcut to avoid having to click on each + of the remaining squares one by one. + + If you uncover a square which has _no_ mines in the surrounding + eight squares, then it is obviously safe to uncover those squares in + turn, and so on if any of them also has no surrounding mines. This + will be done for you automatically; so sometimes when you uncover a + square, a whole new area will open up to be explored. + + All the actions described in section 2.1 are also available. + + Even Undo is available, although you might consider it cheating to + use it. If you step on a mine, the program will only reveal the mine + in question (unlike most other implementations, which reveal all of + them). You can then Undo your fatal move and continue playing if you + like. The program will track the number of times you died (and Undo + will not reduce that counter), so when you get to the end of the + game you know whether or not you did it without making any errors. + + (If you really want to know the full layout of the grid, which other + implementations will show you after you die, you can always use the + Solve menu option.) + + 12.2 Mines parameters + + The options available from the `Custom...' option on the `Type' menu + are: + + _Width_, _Height_ + + Size of grid in squares. + + _Mines_ + + Number of mines in the grid. You can enter this as an absolute + mine count, or alternatively you can put a % sign on the end + in which case the game will arrange for that proportion of the + squares in the grid to be mines. + + Beware of setting the mine count too high. At very high + densities, the program may spend forever searching for a + solvable grid. + + _Ensure solubility_ + + When this option is enabled (as it is by default), Mines will + ensure that the entire grid can be fully deduced starting + from the initial open space. If you prefer the riskier grids + generated by other implementations, you can switch off this + option. + +Chapter 13: Same Game +--------------------- + + You have a grid of coloured squares, which you have to clear by + highlighting contiguous regions of more than one coloured square; + the larger the region you highlight, the more points you get (and + the faster you clear the arena). + + If you clear the grid you win. If you end up with nothing but single + squares (i.e., there are no more clickable regions left) you lose. + + Removing a region causes the rest of the grid to shuffle up: blocks + that are suspended will fall down (first), and then empty columns + are filled from the right. + + Same Game was contributed to this collection by James Harvey. + + 13.1 Same Game controls + + This game can be played with either the keyboard or the mouse. + + If you left-click an unselected region, it becomes selected + (possibly clearing the current selection). + + If you left-click the selected region, it will be removed (and the + rest of the grid shuffled immediately). + + If you right-click the selected region, it will be unselected. + + The cursor keys move a cursor around the grid. Pressing the Space or + Enter keys while the cursor is in an unselected region selects it; + pressing Space or Enter again removes it as above. + + (All the actions described in section 2.1 are also available.) + + 13.2 Same Game parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. + + _Width_, _Height_ + + Size of grid in squares. + + _No. of colours_ + + Number of different colours used to fill the grid; the more + colours, the fewer large regions of colour and thus the more + difficult it is to successfully clear the grid. + + _Scoring system_ + + Controls the precise mechanism used for scoring. With the + default system, `(n-2)^2', only regions of three squares or more + will score any points at all. With the alternative `(n-1)^2' + system, regions of two squares score a point each, and larger + regions score relatively more points. + + _Ensure solubility_ + + If this option is ticked (the default state), generated grids + will be guaranteed to have at least one solution. + + If you turn it off, the game generator will not try to guarantee + soluble grids; it will, however, still ensure that there are at + least 2 squares of each colour on the grid at the start (since a + grid with exactly one square of a given colour is _definitely_ + insoluble). Grids generated with this option disabled may + contain more large areas of contiguous colour, leading to + opportunities for higher scores; they can also take less time to + generate. + +Chapter 14: Flip +---------------- + + You have a grid of squares, some light and some dark. Your aim is to + light all the squares up at the same time. You can choose any square + and flip its state from light to dark or dark to light, but when you + do so, other squares around it change state as well. + + Each square contains a small diagram showing which other squares + change when you flip it. + + 14.1 Flip controls + + This game can be played with either the keyboard or the mouse. + + Left-click in a square to flip it and its associated squares, or use + the cursor keys to choose a square and the space bar or Enter key to + flip. + + If you use the `Solve' function on this game, it will mark some of + the squares in red. If you click once in every square with a red + mark, the game should be solved. (If you click in a square _without_ + a red mark, a red mark will appear in it to indicate that you will + need to reverse that operation to reach the solution.) + + (All the actions described in section 2.1 are also available.) + + 14.2 Flip parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. + + _Width_, _Height_ + + Size of grid in squares. + + _Shape type_ + + This control determines the shape of the region which is flipped + by clicking in any given square. The default setting, `Crosses', + causes every square to flip itself and its four immediate + neighbours (or three or two if it's at an edge or corner). The + other setting, `Random', causes a random shape to be chosen for + every square, so the game is different every time. + +Chapter 15: Guess +----------------- + + You have a set of coloured pegs, and have to reproduce a + predetermined sequence of them (chosen by the computer) within a + certain number of guesses. + + Each guess gets marked with the number of correctly-coloured pegs + in the correct places (in black), and also the number of correctly- + coloured pegs in the wrong places (in white). + + This game is also known (and marketed, by Hasbro, mainly) as a board + game `Mastermind', with 6 colours, 4 pegs per row, and 10 guesses. + However, this version allows custom settings of number of colours + (up to 10), number of pegs per row, and number of guesses. + + Guess was contributed to this collection by James Harvey. + + 15.1 Guess controls + + This game can be played with either the keyboard or the mouse. + + With the mouse, drag a coloured peg from the tray on the left-hand + side to its required position in the current guess; pegs may also + be dragged from current and past guesses to copy them elsewhere. To + remove a peg, drag it off its current position to somewhere invalid. + + Right-clicking in the current guess adds a `hold' marker; pegs that + have hold markers will be automatically added to the next guess + after marking. + + Alternatively, with the keyboard, the up and down cursor keys can + be used to select a peg colour, the left and right keys to select a + peg position, and the space bar or Enter key to place a peg of the + selected colour in the chosen position. `D' or Backspace removes a + peg, and `H' adds a hold marker. + + When the guess is complete, the smaller feedback pegs will be + highlighted; clicking on these (or moving the peg cursor to them + with the arrow keys and pressing the space bar or Enter key) will + mark the current guess, copy any held pegs to the next guess, and + move the `current guess' marker. + + If you correctly position all the pegs the solution will be + displayed below; if you run out of guesses (or select `Solve...') + the solution will also be revealed. + + (All the actions described in section 2.1 are also available.) + + 15.2 Guess parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. The default game matches the parameters for the board + game `Mastermind'. + + _Colours_ + + Number of colours the solution is chosen from; from 2 to 10 + (more is harder). + + _Pegs per guess_ + + Number of pegs per guess (more is harder). + + _Guesses_ + + Number of guesses you have to find the solution in (fewer is + harder). + + _Allow blanks_ + + Allows blank pegs to be given as part of a guess (makes it + easier, because you know that those will never be counted as + part of the solution). This is turned off by default. + + Note that this doesn't allow blank pegs in the solution; if you + really wanted that, use one extra colour. + + _Allow duplicates_ + + Allows the solution (and the guesses) to contain colours more + than once; this increases the search space (making things + harder), and is turned on by default. + +Chapter 16: Pegs +---------------- + + A number of pegs are placed in holes on a board. You can remove a + peg by jumping an adjacent peg over it (horizontally or vertically) + to a vacant hole on the other side. Your aim is to remove all but + one of the pegs initially present. + + This game, best known as `Peg Solitaire', is possibly one of the + oldest puzzle games still commonly known. + + 16.1 Pegs controls + + To move a peg, drag it with the mouse from its current position to + its final position. If the final position is exactly two holes away + from the initial position, is currently unoccupied by a peg, and + there is a peg in the intervening square, the move will be permitted + and the intervening peg will be removed. + + Vacant spaces which you can move a peg into are marked with holes. A + space with no peg and no hole is not available for moving at all: it + is an obstacle which you must work around. + + (All the actions described in section 2.1 are also available.) + + 16.2 Pegs parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. + + _Width_, _Height_ + + Size of grid in holes. + + _Board type_ + + Controls whether you are given a board of a standard shape or + a randomly generated shape. The two standard shapes currently + supported are `Cross' and `Octagon' (also commonly known as the + English and European traditional board layouts respectively). + Selecting `Random' will give you a different board shape every + time (but always one that is known to have a solution). + +Chapter 17: Dominosa +-------------------- + + A normal set of dominoes - that is, one instance of every + (unordered) pair of numbers from 0 to 6 - has been arranged + irregularly into a rectangle; then the number in each square has + been written down and the dominoes themselves removed. Your task is + to reconstruct the pattern by arranging the set of dominoes to match + the provided array of numbers. + + This puzzle is widely credited to O. S. Adler, and takes part of its + name from those initials. + + 17.1 Dominosa controls + + Left-clicking between any two adjacent numbers places a domino + covering them, or removes one if it is already present. Trying to + place a domino which overlaps existing dominoes will remove the ones + it overlaps. + + Right-clicking between two adjacent numbers draws a line between + them, which you can use to remind yourself that you know those two + numbers are _not_ covered by a single domino. Right-clicking again + removes the line. + + (All the actions described in section 2.1 are also available.) + + 17.2 Dominosa parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. + + _Maximum number on dominoes_ + + Controls the size of the puzzle, by controlling the size of the + set of dominoes used to make it. Dominoes with numbers going + up to N will give rise to an (N+2) x (N+1) rectangle; so, in + particular, the default value of 6 gives an 8x7 grid. + + _Ensure unique solution_ + + Normally, Dominosa will make sure that the puzzles it presents + have only one solution. Puzzles with ambiguous sections can be + more difficult and sometimes more subtle, so if you like you + can turn off this feature. Also, finding _all_ the possible + solutions can be an additional challenge for an advanced player. + Turning off this option can also speed up puzzle generation. + +Chapter 18: Untangle +-------------------- + + You are given a number of points, some of which have lines drawn + between them. You can move the points about arbitrarily; your aim is + to position the points so that no line crosses another. + + I originally saw this in the form of a Flash game called Planarity + [6], written by John Tantalo. + + [6] http://home.cwru.edu/~jnt5/Planarity + + 18.1 Untangle controls + + To move a point, click on it with the left mouse button and drag it + into a new position. + + (All the actions described in section 2.1 are also available.) + + 18.2 Untangle parameters + + There is only one parameter available from the `Custom...' option on + the `Type' menu: + + _Number of points_ + + Controls the size of the puzzle, by specifying the number of + points in the generated graph. + +Chapter 19: Black Box +--------------------- + + A number of balls are hidden in a rectangular arena. You have to + deduce the positions of the balls by firing lasers from positions on + the edge of the arena and observing how they are deflected. + + Lasers will fire straight until they hit the opposite side of the + arena (at which point they emerge), unless affected by balls in one + of the following ways: + + - A laser that hits a ball head-on is absorbed and will never re- + emerge. This includes lasers that meet a ball on the first rank + of the arena. + + - A laser with a ball to its front-left square gets deflected 90 + degrees to the right. + + - A laser with a ball to its front-right square gets similarly + deflected to the left. + + - A laser that would re-emerge from the entry location is + considered to be `reflected'. + + - A laser which would get deflected before entering the arena + (down the `firing range') by a ball to the front-left or front- + right of its entry point is also considered to be `reflected'. + + Lasers that are reflected appear as a `R'; lasers that hit balls + dead-on appear as `H'. Otherwise, a number appears at the firing + point and the location where the laser emerges (this number is + unique to that shot). + + You can place guesses as to the location of the balls, based on the + entry and exit patterns of the lasers; once you have placed enough + balls a button appears enabling you to have your guesses checked. + + Here is a diagram showing how the positions of balls can create each + of the laser behaviours shown above: + + 1RHR---- + |..O.O...| + 2........3 + |........| + |........| + 3........| + |......O.| + H........| + |.....O..| + 12-RH--- + + As shown, it is possible for a ball to receive multiple reflections + before re-emerging (see turn 3). Similarly, a ball may be reflected + (possibly more than once) before receiving a hit (the `H' on the + left side of the example). + + Note that any layout with more that 4 balls may have a non-unique + solution. The following diagram illustrates this; if you know the + board contains 5 balls, it is impossible to determine where the + fifth ball is (possible positions marked with an x): + + -------- + |........| + |........| + |..O..O..| + |...xx...| + |...xx...| + |..O..O..| + |........| + |........| + -------- + + For this reason when you have your guesses checked the game will + check that your solution _produces the same results_ as the + computer's, rather than that your solution is identical to the + computer's. So in the above example, you could put the fifth ball at + _any_ of the locations marked with an x, and you would still win. + + Black Box was contributed to this collection by James Harvey. + + 19.1 Black Box controls + + To fire a laser, left-click in a square around the side of the + arena. The results will be displayed immediately. Lasers may not be + fired twice (because the results will never change). Holding down + the left button will highlight the current go (or a previous go) to + confirm the exit point for that laser, if applicable. + + To guess the location of a ball, left-click within the arena and a + black circle will appear marking the guess; to remove the guessed + ball click again. + + Locations in the arena may be locked against modification by right- + clicking; whole rows and columns may be similarly locked by right- + clicking in the laser firing range above/below that column, or to + the left/right of that row. + + When an appropriate number of balls have been guessed a button will + appear at the top-left corner of the grid; clicking that will mark + your guesses. + + If you click the `mark' button and your guesses are not correct, the + game will show you as little information as possible to demonstrate + this to you, so you can try again. If your ball positions are not + consistent with the laser paths you already know about, one laser + path will be circled to indicate that it proves you wrong. If your + positions match all the existing laser paths but are still wrong, + one new laser path will be revealed (written in red) which is not + consistent with your current guesses. + + If you decide to give up completely, you can select Solve to reveal + the actual ball positions. At this point, correctly-placed balls + will be displayed as filled black circles; incorrectly-placed balls + are displayed as filled black circles with red crosses, and missing + balls are filled red circles. In addition, a red circle marks any + laser you had already fired which is not consistent with your ball + layout (just as when you press the mark button), and red text marks + any laser you _could_ have fired in order to distinguish your ball + layout from the right one. + + (All the actions described in section 2.1 are also available.) + + 19.2 Black Box parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. + + _Width_, _Height_ + + Size of grid in squares. There are 2 x _Width_ x _Height_ lasers + per grid, two per row and two per column. + + _No. of balls_ + + Number of balls to place in the grid. This can be a single + number, or a range (separated with a hyphen, like `2-6'), + and determines the number of balls to place on the grid. + The `reveal' button is only enabled if you have guessed an + appropriate number of balls; a guess using a different number + to the original solution is still acceptable, if all the laser + inputs and outputs match. + +Chapter 20: Slant +----------------- + + You have a grid of squares. Your aim is to draw a diagonal line + through each square, and choose which way each line slants so that + the following conditions are met: + + - The diagonal lines never form a loop. + + - Any point with a circled number has precisely that many lines + meeting at it. (Thus, a 4 is the centre of a cross shape, + whereas a zero is the centre of a diamond shape - or rather, a + partial diamond shape, because a zero can never appear in the + middle of the grid because that would immediately cause a loop.) + + Credit for this puzzle goes to Nikoli [7]. + + [7] http://www.nikoli.co.jp/puzzles/39/index.htm (in Japanese) + + 20.1 Slant controls + + Left-clicking in a blank square will place a \ in it (a line leaning + to the left, i.e. running from the top left of the square to the + bottom right). Right-clicking in a blank square will place a / in it + (leaning to the right, running from top right to bottom left). + + Continuing to click either button will cycle between the three + possible square contents. Thus, if you left-click repeatedly in a + blank square it will change from blank to \ to / back to blank, and + if you right-click repeatedly the square will change from blank to / + to \ back to blank. (Therefore, you can play the game entirely with + one button if you need to.) + + (All the actions described in section 2.1 are also available.) + + 20.2 Slant parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. + + _Width_, _Height_ + + Size of grid in squares. + + _Difficulty_ + + Controls the difficulty of the generated puzzle. At Hard + level, you are required to do deductions based on knowledge of + _relationships_ between squares rather than always being able to + deduce the exact contents of one square at a time. (For example, + you might know that two squares slant in the same direction, + even if you don't yet know what that direction is, and this + might enable you to deduce something about still other squares.) + Even at Hard level, guesswork and backtracking should never be + necessary. + +Chapter 21: Light Up +-------------------- + + You have a grid of squares. Some are filled in black; some of the + black squares are numbered. Your aim is to `light up' all the empty + squares by placing light bulbs in some of them. + + Each light bulb illuminates the square it is on, plus all squares + in line with it horizontally or vertically unless a black square is + blocking the way. + + To win the game, you must satisfy the following conditions: + + - All non-black squares are lit. + + - No light is lit by another light. + + - All numbered black squares have exactly that number of lights + adjacent to them (in the four squares above, below, and to the + side). + + Non-numbered black squares may have any number of lights adjacent to + them. + + Credit for this puzzle goes to Nikoli [8]. + + Light Up was contributed to this collection by James Harvey. + + [8] http://www.nikoli.co.jp/puzzles/32/index-e.htm (beware of Flash) + + 21.1 Light Up controls + + Left-clicking in a non-black square will toggle the presence of a + light in that square. Right-clicking in a non-black square toggles a + mark there to aid solving; it can be used to highlight squares that + cannot be lit, for example. + + You may not place a light in a marked square, nor place a mark in a + lit square. + + The game will highlight obvious errors in red. Lights lit by other + lights are highlighted in this way, as are numbered squares which do + not (or cannot) have the right number of lights next to them. + + Thus, the grid is solved when all non-black squares have yellow + highlights and there are no red lights. + + (All the actions described in section 2.1 are also available.) + + 21.2 Light Up parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. + + _Width_, _Height_ + + Size of grid in squares. + + _%age of black squares_ + + Rough percentage of black squares in the grid. + + This is a hint rather than an instruction. If the grid generator + is unable to generate a puzzle to this precise specification, it + will increase the proportion of black squares until it can. + + _Symmetry_ + + Allows you to specify the required symmetry of the black squares + in the grid. (This does not affect the difficulty of the puzzles + noticeably.) + + _Difficulty_ + + `Easy' means that the puzzles should be soluble without + backtracking or guessing, `Hard' means that some guesses will + probably be necessary. + +Chapter 22: Map +--------------- + + You are given a map consisting of a number of regions. Your task is + to colour each region with one of four colours, in such a way that + no two regions sharing a boundary have the same colour. You are + provided with some regions already coloured, sufficient to make the + remainder of the solution unique. + + Only regions which share a length of border are required to be + different colours. Two regions which meet at only one _point_ (i.e. + are diagonally separated) may be the same colour. + + I believe this puzzle is original; I've never seen an implementation + of it anywhere else. The concept of a four-colouring puzzle was + suggested by Owen Dunn; credit must also go to Nikoli and to Verity + Allan for inspiring the train of thought that led to me realising + Owen's suggestion was a viable puzzle. Thanks also to Gareth Taylor + for many detailed suggestions. + + 22.1 Map controls + + To colour a region, click the left mouse button on an existing + region of the desired colour and drag that colour into the new + region. + + (The program will always ensure the starting puzzle has at least one + region of each colour, so that this is always possible!) + + If you need to clear a region, you can drag from an empty region, or + from the puzzle boundary if there are no empty regions left. + + Dragging a colour using the _right_ mouse button will stipple the + region in that colour, which you can use as a note to yourself that + you think the region _might_ be that colour. A region can contain + stipples in multiple colours at once. (This is often useful at the + harder difficulty levels.) + + If you press L during play, the game will toggle display of a number + in each region of the map. This is useful if you want to discuss a + particular puzzle instance with a friend - having an unambiguous + name for each region is much easier than trying to refer to them all + by names such as `the one down and right of the brown one on the top + border'. + + (All the actions described in section 2.1 are also available.) + + 22.2 Map parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. + + _Width_, _Height_ + + Size of grid in squares. + + _Regions_ + + Number of regions in the generated map. + + _Difficulty_ + + In `Easy' mode, there should always be at least one region whose + colour can be determined trivially. In `Normal' and `Hard' + modes, you will have to use increasingly complex logic to deduce + the colour of some regions. However, it will always be possible + without having to guess or backtrack. + + In `Unreasonable' mode, the program will feel free to generate + puzzles which are as hard as it can possibly make them: the + only constraint is that they should still have a unique + solution. Solving Unreasonable puzzles may require guessing and + backtracking. + +Chapter 23: Loopy +----------------- + + You are given a grid of dots. Your aim is to draw a single unbroken + loop from dot to dot within the grid. + + Some of the square spaces between the dots contain numbers. These + numbers indicate how many of the four edges of that square are part + of the loop. The loop you draw must correctly satisfy all of these + clues to be considered a correct solution. + + Credit for this puzzle goes to Nikoli [9]. + + Loopy was contributed to this collection by Mike Pinna. + + [9] http://www.nikoli.co.jp/puzzles/3/index-e.htm (beware of Flash) + + 23.1 Loopy controls + + Click the left mouse button between two dots to add a line segment + connecting them. Click again to remove that line segment. + + If you are sure that a particular line segment is _not_ part of the + loop, you can click the right mouse button to add a small cross + indicating this. Click again to remove the cross. + + (All the actions described in section 2.1 are also available.) + + 23.2 Loopy parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. + + _Width_, _Height_ + + Size of grid in squares. + + _Recursion depth_ + + Determines how much guesswork and backtracking you will need to + do to solve the puzzle. When this is set to zero (as it is for + all of the `Easy' options in the menu), you should always be + able to deduce the state of an edge without having to guess. If + you increase it, you will have to guess more and more. + + Setting a high value for this option is liable to consume a lot + of CPU time and memory. Be warned! + +Chapter 24: Inertia +------------------- + + You are a small green ball sitting in a grid full of obstacles. Your + aim is to collect all the gems without running into any mines. + + You can move the ball in any orthogonal _or diagonal_ direction. + Once the ball starts moving, it will continue until something stops + it. A wall directly in its path will stop it (but if it is moving + diagonally, it will move through a diagonal gap between two other + walls without stopping). Also, some of the squares are `stops'; when + the ball moves on to a stop, it will stop moving no matter what + direction it was going in. Gems do _not_ stop the ball; it picks + them up and keeps on going. + + Running into a mine is fatal. Even if you picked up the last gem in + the same move which then hit a mine, the game will count you as dead + rather than victorious. + + This game was originally implemented for Windows by Ben Olmstead + [10], who was kind enough to release his source code on request so + that it could be re-implemented for this collection. + + [10] http://xn13.com/ + + 24.1 Inertia controls + + You can move the ball in any of the eight directions using the + numeric keypad. Alternatively, if you click the left mouse button + on the grid, the ball will begin a move in the general direction of + where you clicked. + + If you use the `Solve' function on this game, the program will + compute a path through the grid which collects all the remaining + gems and returns to the current position. A hint arrow will appear + on the ball indicating the direction in which you should move to + begin on this path. If you then move in that direction, the arrow + will update to indicate the next direction on the path. You can + also press Space to automatically move in the direction of the hint + arrow. If you move in a different direction from the one shown by + the arrow, the hint arrows will stop appearing because you have + strayed from the provided path; you can then use `Solve' again to + generate a new path if you want to. + + All the actions described in section 2.1 are also available. In + particular, if you do run into a mine and die, you can use the Undo + function and resume playing from before the fatal move. The game + will keep track of the number of times you have done this. + + 24.2 Inertia parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. + + _Width_, _Height_ + + Size of grid in squares. + +Chapter 25: Tents +----------------- + + You have a grid of squares, some of which contain trees. Your aim is + to place tents in some of the remaining squares, in such a way that + the following conditions are met: + + - There are exactly as many tents as trees. + + - The tents and trees can be matched up in such a way that each + tent is directly adjacent (horizontally or vertically, but not + diagonally) to its own tree. However, a tent may be adjacent to + other trees as well as its own. + + - No two tents are adjacent horizontally, vertically _or + diagonally_. + + - The number of tents in each row, and in each column, matches the + numbers given round the sides of the grid. + + This puzzle can be found in several places on the Internet, and was + brought to my attention by e-mail. I don't know who I should credit + for inventing it. + + 25.1 Tents controls + + Left-clicking in a blank square will place a tent in it. Right- + clicking in a blank square will colour it green, indicating that you + are sure it _isn't_ a tent. Clicking either button in an occupied + square will clear it. + + If you _drag_ with the right button along a row or column, every + blank square in the region you cover will be turned green, and no + other squares will be affected. (This is useful for clearing the + remainder of a row once you have placed all its tents.) + + (All the actions described in section 2.1 are also available.) + + 25.2 Tents parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. + + _Width_, _Height_ + + Size of grid in squares. + + _Difficulty_ + + Controls the difficulty of the generated puzzle. More difficult + puzzles require more complex deductions, but at present none + of the available difficulty levels requires guesswork or + backtracking. + +Chapter 26: Bridges +------------------- + + You have a set of islands distributed across the playing area. + Each island contains a number. Your aim is to connect the islands + together with bridges, in such a way that: + + - Bridges run horizontally or vertically. + + - The number of bridges terminating at any island is equal to the + number written in that island. + + - Two bridges may run in parallel between the same two islands, + but no more than two may do so. + + - No bridge crosses another bridge. + + - All the islands are connected together. + + There are some configurable alternative modes, which involve + changing the parallel-bridge limit to something other than 2, and + introducing the additional constraint that no sequence of bridges + may form a loop from one island back to the same island. The rules + stated above are the default ones. + + Credit for this puzzle goes to Nikoli [11]. + + Bridges was contributed to this collection by James Harvey. + + [11] http://www.nikoli.co.jp/puzzles/14/index-e.htm + + 26.1 Bridges controls + + To place a bridge between two islands, click the mouse down on one + island and drag it towards the other. You do not need to drag all + the way to the other island; you only need to move the mouse far + enough for the intended bridge direction to be unambiguous. (So you + can keep the mouse near the starting island and conveniently throw + bridges out from it in many directions.) + + Doing this again when a bridge is already present will add another + parallel bridge. If there are already as many bridges between the + two islands as permitted by the current game rules (i.e. two by + default), the same dragging action will remove all of them. + + If you want to remind yourself that two islands definitely _do not_ + have a bridge between them, you can right-drag between them in the + same way to draw a `non-bridge' marker. + + If you think you have finished with an island (i.e. you have placed + all its bridges and are confident that they are in the right + places), you can mark the island as finished by left-clicking on it. + This will highlight it and all the bridges connected to it, and you + will be prevented from accidentally modifying any of those bridges + in future. Left-clicking again on a highlighted island will unmark + it and restore your ability to modify it. + + Violations of the puzzle rules will be marked in red: + + - An island with too many bridges will be highlighted in red. + + - An island with too few bridges will be highlighted in red if it + is definitely an error (as opposed to merely not being finished + yet): if adding enough bridges would involve having to cross + another bridge or remove a non-bridge marker, or if the island + has been highlighted as complete. + + - A group of islands and bridges may be highlighted in red if it + is a closed subset of the puzzle with no way to connect it to + the rest of the islands. For example, if you directly connect + two 1s together with a bridge and they are not the only two + islands on the grid, they will light up red to indicate that + such a group cannot be contained in any valid solution. + + - If you have selected the (non-default) option to disallow loops + in the solution, a group of bridges which forms a loop will be + highlighted. + + (All the actions described in section 2.1 are also available.) + + 26.2 Bridges parameters + + These parameters are available from the `Custom...' option on the + `Type' menu. + + _Width_, _Height_ + + Size of grid in squares. + + _Difficulty_ + + Difficulty level of puzzle. + + _Allow loops_ + + This is set by default. If cleared, puzzles will be generated in + such a way that they are always soluble without creating a loop, + and solutions which do involve a loop will be disallowed. + + _Max. bridges per direction_ + + Maximum number of bridges in any particular direction. The + default is 2, but you can change it to 1, 3 or 4. In general, + fewer is easier. + + _%age of island squares_ + + Gives a rough percentage of islands the generator will try and + lay before finishing the puzzle. Certain layouts will not manage + to lay enough islands; this is an upper bound. + + _Expansion factor (%age)_ + + The grid generator works by picking an existing island at random + (after first creating an initial island somewhere). It then + decides on a direction (at random), and then works out how far + it could extend before creating another island. This parameter + determines how likely it is to extend as far as it can, rather + than choosing somewhere closer. + + High expansion factors usually mean easier puzzles with fewer + possible islands; low expansion factors can create lots of tightly- + packed islands. + +Appendix A: Licence +------------------- + + This software is copyright 2004-2006 Simon Tatham. + + Portions copyright Richard Boulton, James Harvey and Mike Pinna. + + Permission is hereby granted, free of charge, to any person + obtaining a copy of this software and associated documentation files + (the "Software"), to deal in the Software without restriction, + including without limitation the rights to use, copy, modify, merge, + publish, distribute, sublicense, and/or sell copies of the Software, + and to permit persons to whom the Software is furnished to do so, + subject to the following conditions: + + The above copyright notice and this permission notice shall be + included in all copies or substantial portions of the Software. + + THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS + BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN + ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE + SOFTWARE. + +[$Id: puzzles.but 6513 2006-01-08 18:18:11Z jacob $] diff --git a/version.def b/version.def new file mode 100644 index 0000000..faa7566 --- /dev/null +++ b/version.def @@ -0,0 +1 @@ +-DREVISION=6526 -- 2.11.4.GIT