ScummVM and AmigaOS4.1 F.E.

@kas1e

At least it was worth it, trying to gl4es scummvm.

Some bugs already identified and fixing in progress.



Thank you for clinging to it

@Raziel
Move futher:

ptitSeb fix issue with second crash, so, now all the code from scummvm's dev in our ticket are works over gl4es now.

And as we go further i can now test and pure OpenGL rendering (so ARB shaders + little internal ones), and i can use OpenGL with Shaders (so bunch of those GLSL shaders coming with a game). And so, firstly tried to deal with pure opengl rendering (so ARB shaders), and GL4ES on X86/Linux have _the same_ issue as we have on OS4 ! Yeah!

Mean it's another issue on gl4es side. Made a report about, and trying to help ptitSeb to pinpoint all the shit about. There seems not just "missed person" only, but also something with "depth" are wrong too.

BZ there about: https://github.com/ptitSeb/gl4es/issues/374

@kas1e

Awesome, couldn't have hoped for bugs in gl4es to be squashed due to scummvm.

@Raziel
At least 3 bugs already fixed in GL4ES and surely one or two more to fix.

in meantime i also tried "OpenGL with Shaders" and it also have some strange rendering bugs which seems to happens only on OS4 so somethng to be fixed on our side probabaly too.

But firstly need to deal with pure "OpenGL" as maybe it will cross-reference bugs with "opengl with shaders" and then deailing with them.

After that we will need to test all the ScummVM's games which had shaders with. As far as i see there are 4 : grim (Grim Fandango and Escape from Monkey Island games), Myst3, Stark (The Longest Journey game) and Wintermute (many games). There also some "playground3d" engine but it seems for testing purposes only or somethning..

Also intersting : if game do not have shaders coming with but we still choose "OpenGL with Shaders" will it anyhow different with pure "OpenGL" ? Or if there no shaders coming with tested game then i will be the same as pure "OpenGL" ?

@kas1e

If an engine doesn't report itself as 3D then shaders won't be used (or so I understand it).

Same with other games...there is always a fallback, so I guess, yes, it will fall back to use OpenGL (w/o shaders), but we need to test, of course.

@Raziel
As i wrote in other topic, seems there some "depth" issues which can be not fixable in gl4es (because of how gles2 drivers works, not only for os4, but everywhere), but that to be seen.

But anyway, as we have ogles2, we then better to made ogles2 to work, and so we loose with lehilousophe about 5 hours yesterday, and find out what were the problems with direct ogles2 usage in GRIM : turns out there few little issues , one in their shaders (where they didn't take endianes into account) and another seems in ogles2 which i not very well understand for now, but something about "it should do flipping as all OpenGL surfaces by default", but that to be invistigated today more.

But with all test fixes in place, we have 60 FPS minimum in the GRIM jumping to 210 (!) FPS in gameplay depends on the place.

See: https://youtu.be/w3TcaBVQOIU

Next i tried Myst3 and Long Journey - those shaders seems ok as they are.

And last one in tests was Monkey4 : this one render all persons in "black". So somethng to check about fragment shaders probably.

See : https://youtu.be/24DjuPTVIgw

Wintermute engine i didn't test at the moment, that to be next and last one which use external glsl shaders in scummvm

@kas1e

There was an endian fix from @lephilousophe for z-depth.

I cant test since I'm still working, but maybe that will already fix something too?

If you get the chance (and have some spare time) you can take a look at AGS games (black screen/crash)

@Raziel
Quote:

Yes, that the one i explain things about in previous post.

Quote:

Of course, that the things we find yesterday after hours of debugging. What he commit is one fix: to fix rendering of the main hero. But there still issue with parts being overwritten by hero because of "not fliping images by ogles2" , while it should probabaly. lephilousophe trying to made simple test case so we can report it on Daniel/Hans if it will be something to fix.

But if they will not by any reasson it all can be fixed in the shaders easy too for os4 release.

Quote:

Firstly want to deal fully with all the shaders/ogles2/etc moments of course.

Also there something really bad about "paths" and themes and co. And it seems happens also on linux too.

Also all those warning errors about unimplemented AmigaOS's CreateDirectory() and stuff, need to be deal too.

@kas1e

Sorry, I'm way behind.

Thank you for taking care.

Yeah that missing createDirectory should be easy to add (not for me obviously)

BTW am I the only one where the installer failed to install the whole package ? it just report a "unable to open the tool "Scummvm_install""

Snoopy does not show anything...

nice progress though !

@Raziel
Tested more heavy other games which use external shaders, especially WME3D engine and such games as Alpha Polaris, Art Of Murder 1: FBI Confidential, Dead City, Dark Fall Lost Souls and Face Noir. All of them seems ok (except of Face Noir, but this one renders the same bad on Win32 build too).

So in terms of external shaders we have issues only with GRIM (and they all now left only because of that unknown FBO problem about which Lephilousophe should create a test case soon or later) and some issue with fragment shaders in Monkey (where all persons render black, so that one will be next to deal with).

I also do test all the other games which not use shaders, over ogles2 build directly and all works correctly, at least Full Throttle, 7th Guest, FullPipe, etc.

And in end i create another BZ about WME3D which you also meet with but wan't able to describe it properly: https://bugs.scummvm.org/ticket/13375
Problem happens not only on amigaos4, but on win32 and linux too, so it's general issue.

In other words, deal with FBO bug in grim, deal with shaders bug in Monkey4 , a bit fine tune Lephilousophe commit about those "backend" changes (which imho have no needs for us _imho_ as all can be done automatically) and from 3d side all will be ready.

@kas1e



Great to hear, thanks a lot so far

@Raziel
Soo.... Daniel already working with issue about colors and VBO, and Hans will probabaly fix issue with FBO in Nova on next week.

In meantime we spend 3 days with lephilousophe to find out wtf with all that black colors, and we got at first day that it's "light" issue, on next day we try all the possible stuff with no logic behind, and today, he found what issue was. In short, issue is in ScummVM, but there is long intersting story about (someone may find it interesting):

Firstly we found that something wrong also with "light" in GRIM too, it's too dark. But GRIM game and Monkey4 do share the same "grim" engine, and while shaders a bit different, they still looks comparable enough, and the scummvms opengl-shader code of engine are used the same.

Next we thing that issue in ogles2, and so, it mean that engines like WME3D and The Lonj Journey also should have those issues with light: but not.

Then, as it start to be clear that issues is in the GRIM engine only, he start study the code and then found that issue probably not ogles2, but "an error in the use of glGetUniformLocation in ScummVM" and that it's just that OGLES2 is more strict relative to specs.

He looked at where we have arrays of uniforms in shaders: we have multiples arrays for lights in GRIM and Monkey4, TLJ has arrays for bones and one array of structures for lights, WME3D has one array of strctures for lights too. Then some more research and:

1. in TLJ and WME3D for lights we access each uniform using the following "lights[%d].attribute". In TLJ for bones we access using the following "bonesPosition" and set an array of vectors.

2. In GRIM and Monkey4, we access lights using "lightAttribute[%d]"

But specs says:

Quote:

So, we are not supposed to look up uniforms which are not structures using the syntax with [] and .

We then add some debug prinfs, and find out that for all chaneels but not for [0] we have -1, (the [0] seems to work because the spec seems to say we can address an array using the [0] construct).

I was thinking that it just mesa on linux and windows drivers are extendend a bit out of specs, but no, he did some test on mesa, to find out that if he use original shaders, all uniforms exist but if he change the for loop to only go from 0 to < 1 (instead of maxLights) then all others uniforms return -1.

So it works on Mesa just by pure luck, and code in scummvm fucked.

And he think it's all just because of that "fix" https://github.com/scummvm/scummvm/pull/2618 , which wasn't done good enough.

In other words, another bug he will deal with in ScummVM.

@Raziel
Oh and he did it already. See (click open in new tab for fullsize):





See,there we fix 2 bugs at once, Monkey4 have no colors and GRIM start to looks more "light" not too dark as before.

Now i annoy him to check also MYST3 transition bug: https://bugs.scummvm.org/ticket/13169

But even if he didn't in terms of shaders all done. From side of scummvm he fix everything, and only 2 bugs left to deal on our (ogles2/warp3dnova) side.

@kas1e



I'd never been able to find that, let alone fix it.

Great work

@Raziel
You probabaly noticed from ScummVM commits log if you follow it, that lephilousophe commit all the changes/fixes about ogles2, fixes in shaders, etc, etc. So now, you only need wait a little bit so Mattew will release newer versions of ogles2 and warp3dnova libraries, and things will works as should from ScummVM.

At least GRIM, Monjey, Journey, WME3 engine, etc all of them works over ogles2 with all shaders working ,etc.

The only issue left is issue with Myst3, but this one i hope will be deal with soon. But this issue is not shaders based, but other stuff, so from side of shaders, etc all should be ok now.

Thanks to lephilousophe for his help to find the roots of issues, we fixed 4 bugs in ogles2/warp3dnova and about the same amount in ScummVM itself, which by luck wasn't arise on other platforms.

With ogles2 all opengl games works as expected much faster in compare with minigl and have all features enabled, like for example FBO, which mean it possible to have resized window in Grim and Monkey, while not with MiniGL where FBO didn't work.

@kas1e

Great work.

I wouldn't have been able to do it myself, at least not in the time you managed it.

Thank you

@kas1e

Did you had the time to investigate about the theme issue?
Btw, as usual great work of testing mate!

@kas1e

So, if i followed the activity on the PR correctly, it should (after merge) fall back to OpenGL if no gl4es is found (or does it use OpenGLES2 then?)

Do i still need to build it with your special gl4es libraries or does it use the "normal" ones and OpenGLES2?

/confused

@Raziel
Nope, we don't use gl4es anymore, its of no needs as we use ogles2 directly with scummvm and it works fine (will works after next enhancer update with updated ogles2 and warp3dnova library. But don't worry, without update even gl4es version will not works too, so that no difference in terms of needs to wait).

And it works like this : firstly it try to run ogles2 working (As it faster, and better , and co). If find, then scummvm use that. If not find, then it automatically swith to minigl and use this instead. And if minigl not find, then to software.

It still possible to control from config file to set minigl even if you have ogles2, but that surely no one will do (except ones who want to test/debug some things).


So, you build scummvm without anything additional. No needs for any special -lSDL2_gl4es, or -lGl4ES, you just build it as before. And scummvm will check on running it it have working ogles2, then will use it , if not , will fallback to minigl, if not, will fallback to software

I.e. no more gl4es with scummvm , we use directly ogles2 now.