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

M. Kiewitz m_kiewitz at scummvm.org
Fri Mar 31 12:14:18 UTC 2023


Hello Miro,


As far as I remember - and mind you I haven't worked w/ ScummVM
sourcecode for years, but I doubt that has changed - the SCI engine has
to call it way more often simply and especially because of mouse cursor
updates.

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.

The original interpreter used interrupts for the mouse cursor, and that
made it work smoothly. It was not connected to the game loop.

There may have been additional problems, including special cases.

Same for AGI, where some games block execution (for example tight inner
loop), and thus no updateScreen() was called. I had to implement
heuristics to detect such scripts and implement counter measures. And
the same issue applies there, the mouse cursor will become jittery
without more calls, well obviously because when the game runs at 10 fps,
you only get 10 mouse cursor updates per second as well.


I remember adding special code to the SCI transition graphical effects
code, that auto-detects how fast the backend is able to handle
updateScreen() calls and do less if the backend can't process them fast
enough, because in some backends the transitions worked fine, in others
they made it all slow down to a crawl. And the transitions are supposed
to be pretty fast, but still visible. Fun fact: the original interpreter
ran them as fast as possible, which made some transitions basically
invisible when running on powerful hardware. And we even got at least
one bug report complaining about this weird screen effect with a "broken
palette" and that not being the case in DOS and I had to explain to the
user what was actually going on.


Kind Regards

  Martin




More information about the scummvm-devel mailing list