<div dir="ltr"><div dir="ltr">On Fri, 31 Mar 2023 at 14:14, M. Kiewitz via scummvm-devel <<a href="mailto:scummvm-devel@lists.scummvm.org">scummvm-devel@lists.scummvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Games themselves run typically at a low frame rate, so if you really do<br>
just one call per frame, the mouse cursor will not be smooth anymore,<br>
but very jittery and it will all feel wrong. That was the case in SCI32<br>
for a while.<br></blockquote><div>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.</div><div><br></div><div>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:</div><div><ul><li>do place something like flushScreen() or updateScreen(true) into every Engine::run()</li><li>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)</li><li>when received updateScreen(true), again, either ignore the flag or flush dirty rectangles to screen <i>and</i> the cursor (otherwise it could be overwritten)</li></ul><div>Miro<br></div></div><div><br></div></div><div dir="ltr" class="gmail_signature"><div dir="ltr"></div></div></div>