X-Git-Url: https://git.distorted.org.uk/~mdw/sgt/puzzles/blobdiff_plain/dafd6cf6826f9bbd27ddd780fab48221d4706556..74021716bcfa8fa7ae59c584e3038b7d7a3e5441:/devel.but

diff --git a/devel.but b/devel.but
index 62ec659..ed5c914 100644
--- a/devel.but
+++ b/devel.but
@@ -1551,14 +1551,13 @@ 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
-it is likely (although as yet unimplemented in Puzzles) that 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 \e{possible} to
-write a single (say) \cw{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.
+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
+\e{possible} to write a single (say) \cw{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 \cw{(0,0)} and the bottom right
@@ -2039,11 +2038,11 @@ colour during printing.
 
 \c{r}, \c{g} and \c{b} may each be anywhere in the range from 0 to 1.
 
-If printing in black and white only, the \c{grey} value will not be
-used; instead, regions shaded in this colour will be hatched with
-parallel lines. The \c{hatch} parameter defines what type of
-hatching should be used in place of this colour; see
-\k{print-grey-colour} for its definition.
+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 \c{hatch} parameter defines what type of hatching should
+be used in place of this colour; see \k{print-grey-colour} for its
+definition.
 
 \S{print-line-width} \cw{print_line_width()}
 
@@ -2455,6 +2454,16 @@ previously got it from \cw{midend_fetch_preset()}
 (\k{midend-fetch-preset}). Thus, this function is usually called in
 response to the user making a selection from the presets menu.
 
+\H{midend-get-params} \cw{midend_get_params()}
+
+\c 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
+\cw{free_params()} function (see \k{backend-free-params}).
+
 \H{midend-size} \cw{midend_size()}
 
 \c void midend_size(midend *me, int *x, int *y, int expand);
@@ -4041,7 +4050,7 @@ Then the main redraw loop will look something like this
 \c         if (x == ui->cursor_x && y == ui->cursor_y)
 \c             value |= CURSOR;
 \c         if (ds->symbol_at_position[y][x] != value) {
-\c             symbol_drawing_subroutine(fe, ds, x, y, value);
+\c             symbol_drawing_subroutine(dr, ds, x, y, value);
 \c             ds->symbol_at_position[y][x] = value;
 \c         }
 \c     }