X-Git-Url: https://git.distorted.org.uk/~mdw/sgt/puzzles/blobdiff_plain/7ce7f1716becc6b72a5f16bb484cb847f48d768f..6ac7613cf2e68fd392b143b594e37440c99943c0:/devel.but

diff --git a/devel.but b/devel.but
index 3d5f6d0..096aa12 100644
--- a/devel.but
+++ b/devel.but
@@ -193,7 +193,9 @@ end module builds a different puzzle.
 \b 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
-\c{list.c} which contains a complete list of those game structures.
+\c{list.c} (constructed automatically by the same Perl script that
+builds the \cw{Makefile}s) which contains a complete list of those
+game structures.
 
 On the latter type of platform, source files may assume that the
 preprocessor symbol \c{COMBINED} has been defined. Thus, the usual
@@ -1454,6 +1456,26 @@ mid-end doesn't even bother calling \cw{anim_length()}
 each game. On the rare occasion that animated solve moves are
 actually required, you can set this flag.
 
+\dt \cw{REQUIRE_RBUTTON}
+
+\dd This flag indicates that the puzzle cannot be usefully played
+without the use of mouse buttons other than the left one. On some
+PDA platforms, this flag is used by the front end to enable
+right-button emulation through an appropriate gesture. Note that a
+puzzle is not required to set this just because it \e{uses} the
+right button, but only if its use of the right button is critical to
+playing the game. (Slant, for example, uses the right button to
+cycle through the three square states in the opposite order from the
+left button, and hence can manage fine without it.)
+
+\dt \cw{REQUIRE_NUMPAD}
+
+\dd This flag indicates that the puzzle cannot be usefully played
+without the use of number-key input. On some PDA platforms it causes
+an emulated number pad to appear on the screen. Similarly to
+\cw{REQUIRE_RBUTTON}, a puzzle need not specify this simply if its
+use of the number keys is not critical.
+
 \H{backend-initiative} Things a back end may do on its own initiative
 
 This section describes a couple of things that a back end may choose
@@ -2119,8 +2141,8 @@ function; see \k{drawing-draw-circle}.
 
 \c void (*draw_update)(void *handle, int x, int y, int w, int h);
 
-This function behaves exactly like the back end \cw{draw_text()}
-function; see \k{drawing-draw-text}.
+This function behaves exactly like the back end \cw{draw_update()}
+function; see \k{drawing-draw-update}.
 
 An implementation of this API which only supports printing is
 permitted to define this function pointer to be \cw{NULL} rather
@@ -2265,7 +2287,7 @@ of the puzzle.
 
 Similarly, \c{ym} and \c{yc} specify the vertical position of the
 puzzle as a function of the page height: the page height times
-\c{xm}, plus \c{xc} millimetres, equals the desired distance from
+\c{ym}, plus \c{yc} 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
@@ -2916,9 +2938,10 @@ base), then there will be two global variables defined:
 \c extern const int gamecount;
 
 \c{gamelist} will be an array of \c{gamecount} game structures,
-declared in the source module \c{list.c}. The application should
-search that array for the game it wants, probably by reaching into
-each game structure and looking at its \c{name} field.
+declared in the automatically constructed source module \c{list.c}.
+The application should search that array for the game it wants,
+probably by reaching into each game structure and looking at its
+\c{name} field.
 
 }