AGS: Slowdown when in dialogue in rainy scenes

[Tea23]

When entering the dialogue selection in rainy scenes, such as at the start of the game with the Allen ghost, or in the midgame on the fire escape with Claude, the rain slows down and the mouse becomes jittery.

Also observed in Gemini Rue.

[criezy]

Could you try again with the latest changes I made? The optimisations I committed today mean ScummVM is using 30% less CPU in average with the few games I tried. The rainy scene with the Allen ghost at the start of Blackwell Convergence was already fine for me, but I was seeing some slowdown on the boat deck at the start of Blackwell Deception, and it is now playing at normal speed.

Note also that daily builds are not optimised, so we know that they will be slower than the release builds. Also if you compile ScummVM yourself, you can use the --enable-optimizations with configure to compile it with the optimisations normally used for release builds.

[Tea23]

Just compiled with optimisations. There seems to be some improvement but there is still some noticeable slow down. I have attached a save game in a rainy scene, talk to the ghost and see if it happens to you as well. Save game was made with the updated Steam version.

[criezy]

I have been testing with that same scene and I could not see any slowdown even before my changes.

One thing I noticed is that using your savegame the rain continues to fall when the dialog choices are displayed on screen. But when I start the game from the start, or load one of my save game the rains freezes during the dialog choices. If I use the original AGS interpreter I get exactly the same behaviour as in ScummVM (and the youtube videos I have watched also shows the same behaviour where the rain freezes during the dialog selection), so this does not appear to be a bug in ScummVM. As I am using the GOG version, a wild guess would be that this is controlled by a setting and that the new Steam version changed the value for that setting, and it gets saved in the savegames.

That being said, even with the rain still falling during the dialog choices (so when using your savegame) I still don't have any slowdown. And watching the CPU usage indicates it is not using any more CPU than when the rain is frozen. It is never using more than 40% of one core for me.

I am using the entry level M1 MacBook, so it is recent, but not particularly high spec (the graphics card is an integrated chip for example). And I am also using the OpenGL graphics mode.

I am not sure what you mean by "OpenGL renderer" though. In ScummVM only the software renderer is implemented in AGS so it will always use that (and then pass the fully composited image to the backend that may use OpenGL to draw the image on screen). So the ScummVM AGS engine itself is not using OpenGL to use hardware acceleration for example. As such the graphics card should have little impact (I would expect any graphics card to be able to blit an already composited image on screen very quickly). The CPU is more probably the bottleneck here. Are you maxing out one CPU when playing through that scene in ScummVM?

[Tea23]

Will just summarise what we discussed on Discord regarding this:

With optimisations, we still get slowdown. FPS (measured using Steam overlay) halves in dialogue scenes but there's no spikes in CPU at all, and my beefy 3300X shouldn't really be getting hurt by such a thing anyway.

Also observed in Gemini Rue now we've worked around that. This is more noticeable since the rain is everywhere.

[criezy]

It looks like this might be a regression in the original ags engine.
Today in the AGS Discord somebody reported that

[he] tested the new versions of AGS, and [he] noticed that when running dialogues, the background loops (which are set to run during dialogs) now slow down considerably.

The issue appears in AGS 3.5.1 and 3.6, but not in 3.5.0.
This was investigated by an AGS dev, and he found this:

I confirm the problem. I observe fps drop from 60 to 30 during dialog options
which looks too round for a coincidence tbh...
[...]
Ah! of course. WaitForNextFrame() function is called twice, once from UpdateGameOnce and second time from within DialogOptions::Run()
basically it waits twice per frame, so it's twice slower
yeah, removing one fixes it. Now I just need to carefuly investigate how did it come to this, and whether removing one in DialogOptions::Run is safe and wont break anything else. Also need to check similar cases in few other game states.
Basically, if some game state calls UpdateGameOnce, then it should not call WaitForNextFrame. OR, alternatively, we have to remove WaitForNextFrame from UpdateGameOnce and call it alongside explicitly each time

Once this is fixed in the ags repository, I will cherry-pick it in ScummVM and you can test again. I am hopeful that what you reported is the same issue and will thus be fixed.

I also learned that the AGS engine has an FPS counter. I will see if I can add an option in ScummVM to allow the user to enable that. In the original AGS you would use --fps on the command line when starting ags.

[criezy]

Fix is in. Please test again with the next nightly (or later) to confirm this was the same issue.

[criezy]

By enable the FPS counter I was able to verify that before the change the FPS drops from 40 to 20 FPS in the dialogs with your save game, and after the change it no longer does.

[Tea23]

Can confirm that the FPS drop is no longer present!