Cleanup: remove the game_state parameter to game_colours(). No game

was actually using it, and also it wasn't being called again for
different game states or different game parameters, so it would have
been a mistake to depend on anything in that game state. Games are
now expected to commit in advance to a single fixed list of all the
colours they will ever need, which was the case in practice already
and simplifies any later port to a colour-poor platform. Also this
change has removed a lot of unnecessary faff from midend_colours().

[originally from svn r6416]
This commit is contained in:
Simon Tatham
2005-10-22 16:44:38 +00:00
parent b44d75aa4e
commit 40fcf516f4
28 changed files with 29 additions and 51 deletions

View File

@ -1104,7 +1104,7 @@ create a fresh drawstate.
\S{backend-colours} \cw{colours()}
\c float *(*colours)(frontend *fe, game_state *state, int *ncolours);
\c float *(*colours)(frontend *fe, int *ncolours);
This function is responsible for telling the front end what colours
the puzzle will need to draw itself.
@ -1115,15 +1115,7 @@ array of three times that many \c{float}s, containing the red, green
and blue components of each colour respectively as numbers in the
range [0,1].
It is passed a sample \c{game_state} in case it needs one, although
currently no puzzle does need this. (In fact, colours are not
reallocated when the game parameters change or a new game is
started, so you can't reliably use this \c{game_state} to allocate a
different number of colours depending on the game. It is probably
actually a mistake to rely on this parameter at all. I ought to
either remove it or fix it; probably the former.)
The final parameter passed to this function is a front end handle.
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 \cw{frontend_default_colour()} (see
\k{frontend-default-colour}) or the utility function called