ScummVM and AmigaOS4.1 F.E.

@Raziel

translation.dat file is placed on the same directory of the themes, maybe if they put it by default in a new directory called "translations" could make things a bit more clearer for end users

Thanks for the help

@all

If someone got the time and motivation to check 3D games again (now that the new ogles2.library is out), that would be grand.

No special tests, just see how it performs and hopefully enjoy

@Raziel
As i was the one who test it with all this 3D stuff on latest beta files when we add opengles stuff, etc, and since my tests no new version of ogles2/warp3dnova were released, then all should be ok.

@kas1e

Yeah, i know and i'm very grateful for all the testing, fixing and pointing out of 3D/Warp stuff.

It would still be nice to have some more people playing around, there may be more hidden bugs around (not in the Warp3D/platform stuff) but in the game engines itself.

edit:
with the latest ogles2.library i finally get ~30 fps in-game in Grim Fandango on my RadeonHD, so awesome

@Raziel
Now when you have RadeonRX working somehow on your x1000, how the speed in Grim now ?:) 60 fps ?

@kas1e

I am down to 23 fps (with a *very* quick test)

Also, it seems as if i'm freezing as soon as there is some load on the gfx card *double bummer*

Probably going back to Radeon HD...not worth it, it seems

@kas1e

Back to RadeonHD

Mmh, what i just found (with another quick test) is that Grim Fandango suffers "hiccups" in the in-game movies.
Pretty much the intro video is the best way to see those.

Whenever a new character should do something there is a slight delay (as if some data is being written to the gfx board, but it shouldn't be so "voisible", should it?)

Both with HD and RX, so it's nothing to do with the hardware, can you confirm?

@Raziel
Quote:

I need to test your latest build from os4depot, maybe something happens with (as with my own there wasn't such issues of course).

Also, be sure that powermanagment didn't trick you : you should run powerprefs after each reboot, and set it to "high", or, add it to startup or something of that sort.

@kas1e

Hmm, do you mean "Power" needs to run to actually use the setting?
That would be a bug then, since Power is a Prefs program and should only be needed to be set once and read in/use the setting on every new boot.

During the short lived tests with the RX i checked two times after setting it to "High" and it stayed there, but if i needed to start it on every boot tot ake the setting into account, this might already have been the problem...

Though even with the setting set (and Power closed again, since it's Prefs) i still got these slowdowns.

But as i said, i don't think it has to do with the hardware, rather with how SDL/ScummVM (maybe even ogles2) sends their data to the card, maybe someone can test with ogles2.lib from Enhancer 2.1 (before the update?)

@Raziel
I mean that PowerPrefs even if running and saved, will not work after reboot, and you need again run it and hit use to make it works. I were explained back in days why it like this, and blablalba, but that how it is : if you want full speed of your RadeonRX, then you should after each boot run power prefs and be sure it set to High and then use/save/whatever.

As for ogles2.lib before update : as i say i do all tests on latest ogles2 lib and latest warp3dnova, exactly those ones who out on the public now. If you have strange hickups, it can be for example debug output enabled or something of that sort.

How else i would put my FPS numbers before and making this video:

On which everything fine and fast ?:) on Video i use ogles2 3.2
, warpdnova 54.14, RadeonRX 2.11

But i also do test with ogles 3.3 and warp3dnova 54.16 and radeonrx 2.11 (exactly the ones which out for the wild) : all fine as well. In GRIM i have 60 FPS at begining, and 145 FPS when go to the corridor. No hickups of course.

Be sure you have of course OpenGL + OpenGL with shaders enabled.


I will try now your ScummVM build as well from os4depot to compare how it reacts , like my own one or not.

@Raziel
Ok, tried your build from os4depot.

Firstly tried to run Grim with OpenGL with shaders, and it fail saying can't find shaders. That was because of the same old problem that you didn't have by default correct paths set and user should do it manually for "extras" and "themes" . Once done, all runs.

But then something wrong. With my build, i have 10.000 FPS in the movies, but with your : 62. In the game's corridor (second scene) i do have in my build 145 FPS, but in your's also 62. It looks like VSYNC enabled, but i disable it for sure in global and game's options.

I even checked scummvm.ini, and vsync=false and in global and in grim's settings, but still, 60 fps only everywhere.

On your hardware very possible that you have the same "vsync enabled by some reassons" and it just drop you to 30FPS or something or to 15 with hickups or so.

So, what need to understand, is why your build is limited to 60 FPS everywhere. It's like hardcore enabling of vsync in the code of scummvm, or so ..

Alternatively, it can be not VSYNC issue, but just build issue, where you not enable full optimisation or kind of.

@kas1e

wrt to Power
I didn't follow the conversations back then, but isn't there a way to automate it during boot?
Start it in the background, let it "use" or "save" without user interaction and go on with your life?
I mean, not to diss this, but the behaviour is a bug imho

wrt to the video
Unfortunately you don't show the intro of Grim Fandango.
Especially when the client is looking up to you after entering the office or when he starts tapping his foot, there is a slowdown before it gains the speed back.
It happens whenever there is a change in the scene, so quite often.

And i'm not trying to diminish your or any others work on this.
It's a giant step forward.
I'm just trying to rule out something in ScummVM that might come from outside the program.

Thanks for the tests.
Since i did get it with both cards it might very well be something that slipped into the program lately as regression, hence why i post this in the ScummVM thread.

I've tried ScummVM with ES2.1 and now with ES2.2.
There is no gain in speed (11-20 FPS) but invisible surfaces and glitches had gone now, great.
However, while Grim runs better, Escape From Monkey Island refuses to work. It runs fine with 2.6 from April (with one warning) but now there is a second message "game id not supported".

@Raziel

Imho you too fast with posting bugreports on them, it can be on our side (with the way how things build or something). Firstly we need to pinpoint if it exactly your build only, or hardware, or scummvm itself, etc.

Quote:

Intro did give 10.000 fps , really, there is how it looks like for my build from April:




But your build on exactly same hardware and libs/drivers/etc, on the same intro scene gives just 60-62 FPS.

At the moment for me it looks like something with your build. Maybe forgotten -O2 or something of that sort, or maybe since April they do broken something in ScummVM dunno.. But i do have slowdown in FPS when i build ScummVM without optimisation enabled.


@mr2

Try with my binary, it static, compiled only to support 3D games, and see if it give you real speed (be sure disabled vsync):


https://kas1e.mikendezign.com/aos4/scu ... s_2022_14_april_2_6_0.lha


@raziel

Try also my binary as well, to see if it will react different for you, so it can bring a bit of light if hichup problem is problem of your build or not.

@kas1e

It requires newlib.library >53.68 ....Probably beta?

@kas1e

The release build follows release rules.

Built with --enable-release which means all optimizations on, all debug off.

It doesn't get more optimised than that without tinkering with the source.

I can't test anymore for now, back at work

@Raziel

Intro on built from April shows 400-500 fps, latest version from OS4Depot shows 40-50 fps. Tried with Vsync on/off.....

@mr2
Yeah, so skip it then. Because if your own test show heavy speed drop between aprils anf today build, mean or scummvm regression in code or build optimisation in makefiles broken now.

400-500fps in intro in april build also a bit low. That on sam440 ?

@Raziel
Yeah i know how it supposed to be, but maybe build scripts were messed out somehow and something was added/removed since then.

The easy way to find out what wrong is step by step check builds since april.

What says mr2 mean those possible issues: - or release build process borks
- or regression in scummvm code happens (amiga or general specific).

But what bother me most, is that os4depot release broken then and we need as fast as possible reupload with fixed version once we find what wrong with this build

@Raziel
I build today's source code of scummvm : 62 FPS as well ! Damn shit, somewhere regression in their code.

EDIT: and strangely i didn't see opengl output in console anymore.. Maybe we just fallback to software by some reassons ?

@kas1e

Question...do you use

to install your binary or do you install the build manually.

Because using above will strip the binary and plugins with

by default.

I need to test if keeping this kind of debug info could possibly be the cause of those slowdowns...then again, this change is older than April and eas added to also get rid of random crashes...mmh