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.
>
> > * 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?
>
Yes.
>
> > 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
