aboutsummaryrefslogtreecommitdiff
path: root/samegame.c (follow)
Commit message (Collapse)AuthorAge
* draw_polygon() and draw_circle() have always had a portabilitySimon Tatham2005-07-03
| | | | | | | | | | | | | | | | | | | constraint: because some front ends interpret `draw filled shape' to mean `including its boundary' while others interpret it to mean `not including its boundary' (and X seems to vacillate between the two opinions as it moves around the shape!), you MUST NOT draw a filled shape only. You can fill in one colour and outline in another, you can fill or outline in the same colour, or you can just outline, but just filling is a no-no. This leads to a _lot_ of double calls to these functions, so I've changed the interface. draw_circle() and draw_polygon() now each take two colour arguments, a fill colour (which can be -1 for none) and an outline colour (which must be valid). This should simplify code in the game back ends, while also reducing the possibility for coding error. [originally from svn r6047]
* General robustness patch from James Harvey:Simon Tatham2005-06-30
| | | | | | | | | | | | | - most game_size() functions now work in doubles internally and round to nearest, meaning that they have less tendency to try to alter a size they returned happily from a previous call - couple of fiddly fixes (memory leaks, precautionary casts in printf argument lists) - midend_deserialise() now constructs an appropriate drawstate, which I can't think how I overlooked myself since I _thought_ I went through the entire midend structure field by field! [originally from svn r6041]
* New {en,de}code_ui functions should be static. Oops.Simon Tatham2005-06-28
| | | | [originally from svn r6031]
* More serialisation changes: the game_aux_info structure has now beenSimon Tatham2005-06-28
| | | | | | | | | | | | retired, and replaced with a simple string. Most of the games which use it simply encode the string in the same way that the Solve move will also be encoded, i.e. solve_game() simply returns dupstr(aux_info). Again, this is a better approach than writing separate game_aux_info serialise/deserialise functions because doing it this way is self-testing (the strings are created and parsed during the course of any Solve operation at all). [originally from svn r6029]
* Another function pair required for serialisation; these ones saveSimon Tatham2005-06-28
| | | | | | | | | | | and restore anything vitally important in the game_ui. Most of the game_ui is expected to be stuff about cursor positions and currently active mouse drags, so it absolutely _doesn't_ want to be preserved over a serialisation; but one or two things would be disorienting or outright wrong to reset, such as the Net origin position and the Mines death counter. [originally from svn r6026]
* Re-architecting of the game backend interface. make_move() has beenSimon Tatham2005-06-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | split into two functions. The first, interpret_move(), takes all the arguments that make_move() used to get and may have the usual side effects of modifying the game_ui, but instead of returning a modified game_state it instead returns a string description of the move to be made. This string description is then passed to a second function, execute_move(), together with an input game_state, which is responsible for actually producing the new state. (solve_game() also returns a string to be passed to execute_move().) The point of this is to work towards being able to serialise the whole of a game midend into a byte stream such as a disk file, which will eventually support save and load functions in the desktop puzzles, as well as restoring half-finished games after a quit and restart in James Harvey's Palm port. Making each game supply a convert-to-string function for its game_state format would have been an unreliable way to do this, since those functions would not have been used in normal play, so they'd only have been tested when you actually tried to save and load - a recipe for latent bugs if ever I heard one. This way, you won't even be able to _make_ a move if execute_move() doesn't work properly, which means that if you can play a game at all I can have pretty high confidence that serialising it will work first time. This is only the groundwork; there will be more checkins to come on this theme. But the major upheaval should now be done, and as far as I can tell everything's still working normally. [originally from svn r6024]
* Redraw glitch: tiles marked black (at game-over time) were notSimon Tatham2005-06-19
| | | | | | | | | | | | redrawn as non-black on undo. Introduce a new flag TILE_IMPOSSIBLE, so that information about those black markers is cached in the drawstate and we know when we have to erase them. In the process I've removed the game_state argument completely from the subfunction tile_redraw(), which gives me some confidence that it isn't getting any _more_ privileged information out of it. [originally from svn r5979]
* Infrastructure change which I've been thinking about for a while:Simon Tatham2005-06-17
| | | | | | | the back end function solve_game() now takes the _current_ game_state in addition to the initial one. [originally from svn r5969]
* Patch from James Harvey to rearrange the Same Game colours.Simon Tatham2005-06-10
| | | | [originally from svn r5938]
* Remove debug output.Jacob Nevins2005-06-08
| | | | [originally from svn r5926]
* Add Windows help topicJacob Nevins2005-06-07
| | | | [originally from svn r5923]
* James Harvey's patch to support keyboard control in Same Game.Simon Tatham2005-06-07
| | | | [originally from svn r5919]
* James Harvey has contributed an implementation of `Same Game', alsoSimon Tatham2005-06-07
known as ksame (KDE) and Same GNOME (GNOME). [originally from svn r5914]