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

Joost Peters joostp at 7fc1.org
Wed Mar 15 15:50:06 CET 2006


The PSP port (and, AFAIK, atleast the PS2 port too) behave the same as 
the Dreamcast port in this regard (i.e. they only update the mouse 
cursor on-screen via updateScreen()), which so far has usually been 
sufficient.

The documentation does indeed not say who (engine or backend) is 
responsible for drawing it.
I don't really have a preference for either option.


Joost


Max Horn wrote:
> 
> 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
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
> 




More information about the Scummvm-devel mailing list