SCI Games begin lagging either at launch or after moving about outside of window

[NikkiPhoenix80]

I was trying to play some Quest for Glory today on ScummVM 2.5.0. Up until today, I was able to play the games comfortably and without issue. Today, booted it up for stream, and there was anywhere from a 5 to 60 second lag between keyboard presses and mouse clicks. This was in any SCI game, and I played it with QFGI, KQIV, SQIII, and Conquest of Camelot. Same issue in all games. Booted up AGI games, worked beautifully. To combat this, I ended up downgrading to v2.2.0 and all SCI games were working wonderfully.

[eriktorbjorn]

I can't reproduce this with the Linux version of ScummVM. Is it only SCI games, or is it all games? Does it happen from the very beginning of the game, or does it take a while? Does changing the Graphics settings (e.g. changing the "Graphics mode" between "SDL Surface" and "OpenGL") make any difference?

[shdon]

I was on a troubleshooting session with Nikki after she encountered this (and am the one who recommended that she file this as a bug). Although I didn't experience it myself even when I updated my own ScummVM's installation to match her settings, I did witness it on her PC when she shared the desktop. The effect was real and quite pronounced.

Some pertinent information:

• it happened only with SCI games and did so with all of the ones we tried
• games tested with AGI (SQ2) and SCUMM (MI3) showed no issues
• reboot had no effect
• repair install of ScummVM had no effect
• changing sound drivers or even disabling sound altogether had no effect (we checked this because there was apparently some audio distortion, though I couldn't hear that through the desktop sharing)
• switching graphics modes had no effect
• the delay was not immediate. When starting the games, they would work fine. The delay only got introduced when doing something outside of the ScummVM viewport (like alt-tabbing out, clicking on another window, or even just moving/resizing the ScummVM viewport window). The more "mucking about outside ScummVM" there was, the longer the delay was. Maybe just one or two seconds at first, but could easily end up being half a minute.
• Nikki would click somewhere to make the character walk there and it wouldn't start walking for several seconds, but the walking animation itself would play at normal speed
• the same with pressing a cursor key to walk... several seconds before the game registered the input
• Nikki would right-click on an object to get the description (QfG1 uses right-click to look-at) and there too, the dialog box would pop up after several seconds.

The odd thing is that, just 2 days prior, there were no issues at all with the very same settings and installation. And also that I couldn't reproduce it on my machine even as I was watching it happen on hers. The downgrade from 2.5 to 2.2 at least made the games playable again, but obviously isn't a very satisfactory workaround or diagnosis. As far as Nikki knows, the only changes to the system configuration around that time may have been the .NET framework being updated to a more recent version, though that probably isn't related - just mentioning it for completeness.

[sluicebox]

Wow; some serious troubleshooting! Thanks for reporting this.

eriktorbjorn's suggestion to try switching between the "Graphics mode" setting was my first thought too. 2.5.0 changed the Windows default mode from SDL Surface to OpenGL. If that's the problem, it may even happen in 2.2.0 with the mode set to OpenGL. Either way, that should be easy to test and would reveal a lot about the nature of the problem.

(And we've now established this is Windows since .NET framework was mentioned.)

This sounds too interesting of a problem for the SCI engine; I just can't think of any SCI changes in 2.5.0 that could have such a wide ranging effect. But there were lots of graphics code changes. And the new default means that OpenGL mode is suddenly getting a lot more use than it did before, and that could mean discovering weird incompatibilities.

Other details that could help reproduce/understand this:

• What streaming software?
• What Windows version?
• You could attach your scummvm.ini file from when this occurs; that way we could see what all the settings are and try them ourselves. (It's a text file, feel free to remove irrelevant games or local paths you don't want included)

Oh, and if you haven't already, could you try our daily build in case this has already been fixed since the 2.5.0 release?

Daily builds packaged in installers: ​https://www.scummvm.org/downloads/#daily
Daily builds packaged in zip files: ​https://buildbot.scummvm.org/#/dailybuilds

[NikkiPhoenix80]

I am using Windows 10.
I tried both the SDL and the OpenGL video modes, however neither made a difference.
My streaming software is OBS Studio, which I had moved to from Streamlabs long before the issues began.
I'll try the daily builds, keeping 2.2 in reserve for now.