Hi,
> > > * The way I see it (TWISI?) we can't handle RestartGame TWSUTDT,
> > > beceause of the way we implement game_state_t. This may require a
> > > restructuring of our code.
> >
> > I disagree :-)
>
> I'm not saying we can't do it in a different way... I'm just saying that some
> games may complain. The code for <gameobj>::replay() may need some startup
> conditions to be met, which the definitely won't be if we use a fresh
> game_state_t. And we can't just use <gameobj>::play instead, cf. the PQ2
> example.
After run_vm() exits in vm.c, line 1679, we either have
(s->restarting_flags & SCI_GAME_IS_RESTARTING_NOW), or s->successor set to
a valid, new game state (if both are set, restarting takes precedence-
it's hard to imagine how someone would restart and restore simultaneously,
so this isn't an issue); if neither is set, the game ends.
s->restarting_flags & SCI_GAME_IS_RESTARTING_NOW makes
sure that GameIsRestarting() returns the correct result, resets the vm
exec stack, resets the heap, and calls run_vm() again. I've only tested it
against SQ3; there, it restarts correctly, but then finds some of the
original data in the global (script 0) variables, which makes it continue
where play() left.
There still appear to be things missing. IMHO, just creating a new and
empty game state (and making sure that the restarting flag is set
correctly), would do best... any ideas what it is that PQ2 expects us to
do?
llap,
Christoph
