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.

[originally from svn r6087]
This commit is contained in:
Simon Tatham
2005-07-10 10:06:04 +00:00
parent ac36314b02
commit 145301d0dc
2 changed files with 13 additions and 17 deletions

View File

@ -491,6 +491,10 @@ static int midend_really_process_key(midend_data *me, int x, int y, int button)
me->states[me->nstates].movetype = MOVE;
me->statepos = ++me->nstates;
me->dir = +1;
if (me->ui)
me->ourgame->changed_state(me->ui,
me->states[me->statepos-2].state,
me->states[me->statepos-1].state);
} else {
goto done;
}