ScummVM and AmigaOS4.1 F.E.

@noXLar

No problem.

If you find something just let me know.

@all

Anyone else who tried it?

Thanks

@capehill
@kas1e

I don't want to pollute the glsnoop thread, so here's my problem.

I get massive slowdowns (FPS drop) in Grim Fandango.
I believe it is a regression in the ogles2/opengl driver, because i remember it starting after the latest version hit the public.
Manually bisecting the code didn't help either as every version of ScummVM's code behaves like that now.

I did let glsnoop run over the intro, but i can't make anything out of the numbers, so please take a look



I'd also want to ask you to test Grim Fandango with any version you have and see if the slowdowns are there, e.g. the 2.6.0 release on OS4Depot.net

The slowdowns are all over the gmae but most prominently in the intro right at the beginning
- when Manny opens the door and Selso (the client) looks up to him
- when Selso starts tapping his foot under the chair
- when Manny say "I'm your friend" etc.
really hard to miss as FPS drops from 60 to 10 for me
Also in-game character animations are affected, e.g.
- when Glottis leaves his shack in the garage (here you even see a whole animation skip due to the FPS drop)

Please help, this is way over my head

@Raziel
Wasn't this an issue where they limit the FPS to the "sync", and while on faster machines it behave like 60 FPS, on other ones behave like 30 FPS ? When i create a bug-report about, they just close it, like it all correct to have FPS counter, but limit FPS to the Sync , and even from the menu of scummvm it unpossible to "un-sync" it to have maximum FPS.

From my side i do test it all the times on latest ogles2 and warp3dnova, and with their hardcoded fps limit i have problems with speed, but once i comment out necessary line in the code which do hardcore fps limit, everything back to normal.

You may have on issue because limited fps now depends on the speed, if you can't reach normal 60fps, it will drops to 30 or whatever, if it can't reach 30 in some, it will drops then to 10 or to 15, etc.

In other words, their hardcoded fps limites is for real bad stuff, and they should't do it , even, if it fix some other bugs.

Nothing to do with that, sorry.

I tried revisions even before they capped it, still the same.
I tried revisions where I knew it worked, also still the same.

Also, no other engine is affected (and also also there hasn't been done anything to that specific code in a long time), so it's either something in the gfx driver that changed or the latest SDL2 revision...hmm, need to try the SDL2 settings, maybe

@Raziel

Thanks for the log sample, but based on that profiling period was very short (< 1 second) and there were very few draw calls. I could see 1 Clear and 2 DrawArrays, so almost nothing was renderered during this capture. Also OGLES2 results were not included.

Also calls of TexUpdateSubImage were expensive, average shows 13 ms so that's almost the budget for one frame at 60 FPS (~16 ms).

EDIT: strange, now I see that there are multiple short-lived context creations. Maybe ScummVM is creating the GL context many times. I'm not sure which of the results is relevant, if any.

Does this happen with Grim Fandango demo version? And did you try to remove that suspected frame cap?

Could you also test with Hieronymus? http://os4depot.net/?function=showfil ... ment/debug/hieronymus.lha

SDL2 settings should not impact OpenGL(ES2) applications, they are for SDL_Renderer subsystem (which has multiple driver backends from software to DirectX to OpenGL to Vulkan etc).

@Capehill

Huh that is strange.

I started from cli with 60 seconds to log and let it write ro file with sashimi.
Maybe that was the problem?
Need ro catch the serial log instead.

Yes, I did try without the cap as I wrote above.
The cap was not even there and it still displayed the same behaviour (with higher fps of course, but still a significant fps drop)

@Capehill

Ok, i got something out of serial (and i even see a 100% error line with GetBlendMode...not that i suspect that this may be it)

Quote:
The last one is the relevant one.
ScummVM creates the first context for it's launcher window/screen.
Then a second tiny (100x100 pixels roughly) window is created (no idea why, maybe to check if window creation is possible or something) and immediately destroyed again.
Then the last (game) window/screen is created where all the magic happens.

Thank you very much for looking...and i must say a neat logger you got there