Hi all! I've been looking at the port problems in Jones and some other games, and I've sort of figured it out. Three kernel functions are involved in the (re)drawing of SCI widgets: DrawControl, HiliteControl and EditControl. Like most drawing functions, they obey the currently set port. Therefore it is vital that the correct port be set at the time of the call. You can probably guess that this isn't done in the problematic cases. Why?
The key to answering this question lies in FreeSCI's widget subsystem. When DrawControl is called, it creates a new widget whether it already exists or not. It is my understanding that this is normal, and the widget system is supposed to handle it by destroying the old widget. So far so good. Obviously, SSCI did not use a widget system. This difference is the source of a few problems already (the computer monitor in PQ2 springs to mind). The kicker here is that all three functions may at some point redraw the control if there is a need AND that FreeSCI implements this in the same way in all of them, as described above. It turns out that EditControl is called continuously by the script's widget handling code, without the above precondition being met explicitly. Usually, this is not a problem, because the right port has been set elsewhere, and nothing comes in between to change that (see (2) below). Thus our own widget code is able to handle the situation. In Jones, however, the wrong port is set and our code does not detect the situation. Therefore, the new copy of the widget is allowed to survive, and since it belongs to a different port, is placed at the wrong location. The problem is exacerbated by two things: 1. The fact that EditControl does absolutely nothing with icon controls in SSCI, while FSCI explicitly redraws them. One fix might therefore be to prevent EditControl from redrawing controls it's not supposed to. However, redraws ought to be innocuous, and the solution does not account for "normal" situations, and it is therefore unacceptable in the long run. 2. Jones employs a class called the KeyMouse, allowing you to control the game from a keyboard. This is not the usual way keyboard control is handled (not even in SCI1), but a Jones particularity. As art of its processing it is meant to switch the window manager port temporarily, saving the old one in a property. Due to a bug in the class, this field gets clobbered (also in SSCI), but because of (1), this has no consequences in SSCI. I see the solution as being some kind of change to our widget handling code, but exactly what to change (different widget creation semantics? hash table of previously drawn controls and corresponding ports on the interpreter side of things?), I'm unsure of. Lars _______________________________________________ FreeSCI-develop mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freesci-develop
