[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