Hi,
On Sun, 28 Nov 1999, Lars Skovlund wrote:
[PQ requires RestartGame]
> So we have quite a few related problems at our hands here:
>
> * Simply calling invoke_selector in kRestartGame may eventually fill
> up the execution stack if the game is restarted often enough (we could
> clear the exec stack, though)
Since we're using a non-system stack, clearing it is rather easy. However,
I think that we should implement this the way savegames work, i.e. quit
the execution loop, and start a new exec stack.
> * 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 :-)
> * Even after implementing kRestartGame, the original PQ bug still
> occurs (i.e. the copy protection reappears, although after a longer
> while now)
<expletive/>
Anyway, what exactly does it do again? IIRC, it calls
<gameobj>::restart(), is that correct?
> BTW: AddToPic needs to be prepared to receive a null pointer as a
> parameter. Haven't checked if this is original SCI behaviour or because
> of my particular (and possibly buggy) RestartGame implementation,
> thouugh.
I've fixed it in a way that discards the picview list if
AddToPic(NULL) is run. I don't think that it makes a lot of sense
(picviews are supposed not to change after Animate() is called for the
first time), but if PQ wants it, it can have it.
llap,
Christoph
