Change of policy on game_changed_state(). Originally, it was called
authorsimon <simon@cda61777-01e9-0310-a592-d414129be87e>
Sun, 10 Jul 2005 10:06:04 +0000 (10:06 +0000)
committersimon <simon@cda61777-01e9-0310-a592-d414129be87e>
Sun, 10 Jul 2005 10:06:04 +0000 (10:06 +0000)
commitfaff1e077e6864b40341b49da46e3840e77a6516
tree5c9dcee0d3157b1b64760a7909e199c51b35db56
parent9350f6e3b9903d3dec20d261b4688125fead4f01
Change of policy on game_changed_state(). Originally, it was called
by the midend every time the game state changed _other_ than as a
result of make_move(), on the basis that when the game state changed
due to make_move() the game backend had probably noticed anyway.
However, when make_move() split up, this became more fiddly: if the
game_ui had to be updated based on some property of the final game
state, then execute_move() couldn't do it because it didn't have a
pointer to the game_ui, but it was fiddly to do it in
interpret_move() because that didn't directly have a copy of the
finished game state to examine. Same Game (the only game to be
affected) had to deal with this by actually having interpret_move()
_call_ execute_move() to construct a temporary new game state,
update the UI, and then throw it away.

So now, game_changed_state() is called _every_ time the current game
state changes, which means that if anything needs doing to the
game_ui as a result of examining the new game state, it can be done
there and save a lot of effort.

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@6087 cda61777-01e9-0310-a592-d414129be87e
midend.c
samegame.c