[Scummvm-devel] Re: [Scummvm-cvs-logs] SF.net SVN: scummvm: [21312] scummvm/trunk/engines/kyra/kyra.cpp

[Max Horn]

Am 15.03.2006 um 22:34 schrieb Marcus Comstedt:

>
> Max Horn <max at quendi.de> writes:
>
>>> Revert previous change. I'm told some backends don't draw the mouse
>>> cursor
>>> automatically, for some reason.
>>
>> Hm, interesting. I very vaguely recall something like that, but I am
>> not sure... Could somebody please elaborate a bit and explain which
>> backends are affected, and why?
>>
>> Something fundamental yet subtle like this absolutely should be
>> documented, at the very least in the OSystem doxygen docs. I am
>> willing to do that, but first I need to know why some backends do
>> this etc. :-)
>
>
> I'm not sure if it's relevant for this particular change, but in the
> Dreamcast backend, a call to updateScreen() is needed to update the
> screen (this renders a new scene, and causes a page-flip).  If it is
> not called, the previously rendered scene will simply be shown, and
> nothing moves, including the cursor.


OK, I see... this is indeed quite a big whole in our specs, and the  
SDL backend is kinda problematics, too. Lemme explain:

So far I thought that the following two rules are in effect:
Rule #1: A backend *only* performs a screen update ("flip") when an  
update is *explicitly* requested by a call to updateScreen().
Rule #2: The mouse cursor is automatically updated by the backend  
whenever necessary.

This would have the advantage that engines can control precisely when  
a screen update happens, while not having to worry about mouse  
movement / the mouse cursor. The drawback of course is that some  
burden is put backends, esp. those which render the mouse cursor in  
software. Of course backends with "hardware" rendered mouse cursor  
automatically comply to Rule #2

However, obviously my assumption was wrong (to defend myself, I never  
really thought much about this, I kinda assumed it implicitly without  
ever checking -- bad bad bad):
* the SDL backend simply automatically updates the screen when the  
mouse is moved, so it "violates" rule #1, but rule #2 is fine.
* the DC backend probably conforms to rule #1, but "violates" rule  
#2, since engines must make sure a screen update happens.
* And maybe other backends do other things (porters, chime in and  
tell us how *your* backend handles this).

Now, I see two ways to proceed:
1) We ditch rule #2 and change the SDL backend (and possibly others)  
and remove the updateScreen() call from OSystem_SDL::setMousePos().

2) We implement rule #2 and change the DC backend (and possibly  
others) accordingly. One way would be to let the code which generates  
the EVENT_MOUSEMOVE events to set a flag (screen/mouse needs update),  
which is reset in updateScreen(). Then, at a suitable place, force a  
screen update if that flag is true -- be it simply at the end of  
pollEvent, or with the additional use of a timer (also at the end of  
pollEvent, but only triggers an update if more than N milliseconds  
have passed)...



No matter what we do in the end, I'd prefer to have the expected  
behavior (from engines and from backends) be clear and documented. By  
ensuring our backends behave uniformly in this regard, we reduce the  
number of platform specific bugs, too, and hopefully will catch some  
problems earlier (like that which triggered this thread).


Cheers,
Max