[scummvm-devel] OSystem::updateScreen() issues

Miro Kropáček miro.kropacek at gmail.com
Fri Mar 31 15:03:12 UTC 2023


On Fri, 31 Mar 2023 at 14:14, M. Kiewitz via scummvm-devel <
scummvm-devel at lists.scummvm.org> wrote:

> Games themselves run typically at a low frame rate, so if you really do
> just one call per frame, the mouse cursor will not be smooth anymore,
> but very jittery and it will all feel wrong. That was the case in SCI32
> for a while.
>
This is an interesting observation, I hadn't thought of that. Having
something like updateCursor() or updateScreen(bool updateCursorOnly) would
definitely help but I assume this problem wasn't so obvious when designing
the OSystem class.

Apart from adding / refactoring updateScreen() calls with something like
the above (which is very similar to my proposal to inspect all
updateScreen() calls, i.e. very error-prone and lengthy) I currently can
think of only one approach:

   - do place something like flushScreen() or updateScreen(true) into every
   Engine::run()
   - let the backend decide what to do with updateScreen(false) (default
   parameter): either ignore the flag or treat it as as "flush cursor" (i.e.
   draw cursor over the "old" background) ... even though it is possible that
   it wouldn't be always called due to cursor update, it's harmless (and cheap
   if cursor hasn't moved)
   - when received updateScreen(true), again, either ignore the flag or
   flush dirty rectangles to screen *and* the cursor (otherwise it could be
   overwritten)

Miro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20230331/48d13f45/attachment.htm>


More information about the scummvm-devel mailing list