ScummVM and AmigaOS4.1 F.E.

@Raziel
And something weird with GRIM happens, main person completely missed. But it missed and if i just build with shaders, and if i just build without shaders. I remember 2 months ago when we test it, it works for sure.

Is it still works with minigl builds ? Maybe latest sources just fucked up a bit ?

@kas1e

Quote:
Check with the github PR, portability mostly, but also speed, i guess

Quote:
Not all of them, no.
Right now most of the engines that use shaders get them from within the code.
As new engines emerge they may have external shaders used, not sure though.
Maybe they will switch to external shaders in the future for all engines, maybe even use general shaders which can be accessed from all engines, who knows?
It's a rather "new" addition to ScummVM (merged from ResidualVM, different lead, different codebase, etc....it's coming along)

Quote:
If you built the branch with choosable renderers, you'll gain one extra tab in ScummVM's launcher, called "Platform" iirc.
On there will be three options to choose from: Default (which will be always be OpenGL), OpenGL and ogles2.
If you choose one of them, the renderer will be switched and used automatically.

Quote:
Yes, it does work fine with pure OpenGL.
Don't sweat over it just yet, the main dev told me it might be because of a bug in one of the shaders, he's already investigating.
Nothing to ponder on right now.

@Raziel
Quote:

They can reproduce it too ? I just tried to build scummvm without shaders, and even then no person rendered. It's like something were changed in latest 2 months , because before it surely works over gl4es.

@kas1e

In the very thread/PR you were posting, @lephilosouphe reacted to my "Manny-broken" post in one of the earlier posts, with this answer:
Quote:
You may want to read the thread in full, if you have time
You can even add your findings about the bug there too, but i think that would be out of the scope of this particular PR.

@Raziel
Wait wait, but as i say i tried to build _without shaders_. No shaders in use. And bug still here.

And as i say, before i build it the same way (2 months ago) and all was fine.

I can understand bug in shaders, but if they used. But i tried to build everything without usage of shaders and bug still here

@kas1e

Yes, but you tried with the main tree back then, i assume?

Now you tried with the choose-renderer tree and there were fixes and changes (one most importantly the integration of GLAD and usage of shaders for backends supporting it, inlcuding AmigaOS4), so maybe GLAD overrides the --disable-opengl-game-shaders?

Maybe a newly introduced bug, maybe an oversight, maybe a design choice?

@Raziel

Ok we found : i had to swtich versions by version back, and issue arise once switch to GLAD happen. I currently in discord with lephilousophe, so at least we know for sure its _not_ shaders, but something when migration to GLAD happens. I told you before that such a big changes never passed flawsley :)

Hope it will be not another bug on our side in one of our layers. But at least we will find it now

@kas1e

Heh, i know these things introduce regressions and new bugs

otoh it would be good if it's a bug on our side, wouldn't it?
We'd have another bug squashed which can't bite us later on.

@Raziel
Yeah, the more we find, the less we have, that for sure :)

@Raziel
Tested / restested all different commits, and can say now with 100% that exactly this commit : https://github.com/scummvm/scummvm/com ... 4e43c316759e4ffdb487f244d (BACKENDS: Replace GLEW with GLAD, part of PR #3463) are causing our problems.

Basically it not only GRIM person not renders, if you press "f1" then whole menu not renders too. So it something about texturing and stuff seems so.

GLAD by itself have gazilion of ifdefs/defines, so we need to think how to find what is wrong.

But at least that in no way will stop our progress on shaders front, as it undependent.

I also updated bug report and you also can say to the developer with who you were in touch about that this is not because of shaders, but because of GLAD.

Interestingly through, that MiniGL build works with GLAD fine, that correct ? If so, there should be something trivial-simple somewhere.


@All
Maybe someone may have a clue as well ?

See there is that "GLAD" thing, just a single file:

https://raw.githubusercontent.com/scum ... 4d/graphics/opengl/glad.h

There a lot of ifdefs/ifs, and now since we start to use it in scummvm, we have issues in one of games when no main person rendered and no menu rendered as well.

@All

So, that what we have when we didn't use GLAD but manual loading of the fucntions inside of the scummvm:

on start:



In menu (when press f1):



As can be see all fine.

Now, right after this commit https://github.com/scummvm/scummvm/com ... 4e43c316759e4ffdb487f244d where GLAD were added, we have in the same game that:


On start:



In menu:



See, no person on first screenshot, and nothing at all when hit F1 in menu. Any ideas where to look ?:) It can be or something in that glad.h itself, or something with how it were added to scummvm.



And created new ticked about that issue:

https://bugs.scummvm.org/ticket/13351

Interestingly, i tried to do that: compile everything without shaders with pre-GLAD, and made 2 versions : mgl and gl4es one (compiled with the same 1:1 includs, just link libs differs) - with pre GLAD version it works.

Now, after GLAD added, i compile the same 2 version, with the same includes and link libs as before, and MGL one are fine, GL4ES one have that issue.

Maybe since GLAD added, gl4es build some different internal shaders, and they fail by some reassons to renders properly ? But then, GLAD is nothing but only the describe of functions, the way they loads up, etc ,et .. strange!

@kas1e

I still suspect either one of the shaders or our gl4es has a bug somewhere.

@Raziel
At least if it shaders, its not the shaders coming with the scummvm (As we not use them in our test case), but shaders generated by gl4es internally.

I.e. we not use shaders at all from scummvm in this test cases, they 101% out of question. Only shaders which auto-generated by gl4es can be related maybe.

I thinking about it yesterday as well, so will try not to build 2 versions : gl4es before GLAD, and gl4es after GLAD, then dump all the internal gl4es shaders and compare. As well as dump all the calls via glSnoop and compare too. And we will see if there any difference at all.

GLAD in general is just manager for function pointers for different platforms, etc, so should't cause such issues. But, as we found lately, all sort of weird crap can happens from where you not wait it :) So time to debug !

@Raziel

Some more news.

I tried to build what lephilousophe put into the ticket, and can say that all the compiling shaders issues are gone, they all compiles and executes (and inbuild box.vertex one, and all the other ones comes with games). So his UBOOL macro did the trick.

But now, there are new issue. Now, if i tried to build it via gl4es and run as pure "opengl" 3d-rendering, then it simple crashes. While, when i build yesterday's master Scummvm's sources and fix myself inbuild box.vertex everything works (with non-rendering error because of swith to GLAD of course, but no crash either). So there new issue about, probabaly related to the fact that his delete some stuff there and there.


And, when i run with "opengl with shaders", it runs (so all shaders compiles), not crash, but then didn't rendered properly the same as it was because of issues when we switch to GLAD.

So far we find out from where new crash coming, trying to get rid of it for now in proper way.


And can say , that at least all shaders compiles and works now, because if i fix that crash and use "opengl" only (via gl4es) i have in beginign of GRIM just 47 FPS. If i use "openg with shaders" (via same gl4es), i then have in the same place 67 FPS.

So that mean shaders works, UBOOL macro works, and they all works as +20FPS. Now we only need to deal with that new crash, and with GLAD issues we have (i already asked ptitseb about, so probabaly soon or later we will find wtf)

@Raziel

Some progress:

We open can of worms probabaly :) Bugs and bugs :)

Firstly, there is explain about issue with switching to GLAD (which we need to deal firstly, before going any futher):

https://bugs.scummvm.org/ticket/13351#comment:3

In brief: we have issues with internal auto-generated shaders inside of gl4es when we use ARB_programs_shader extension together with GL_EXT_frag_depth. ARB_shader_extensions at least works as for late (at least from the previous thread where we test SDL2's testshader.c testcase), but not sure if we ever tested GL_EXT_frag_depth properly.

Alternatively it can be bug in gl4es of course too, but, the fact that we have the same issue when we use OGLES2 directly (right? i didn't test it myself now, but sounds that it is ? ) can pointout us on OGLES2/W3DNova, but firstly we need to made more tests.

Another issue with new changes from lephilousophe from original bug-report, is that by some reassons, once we have enabled usage of FrameBuffer we crashes. Before we not, because it was removed due to "not able to compile for MiniGL" , so that will be the second issue to deal with.


Once that all will be deal with, then, we will need to test again GL4ES build with "opengl with shaders" and pure OGLES2 build, to see if it all will be ok, or we will find another, 3rd bug.

Add to that , it seem i meet with that "crash on exit in ogles2 library when clean resourses" as reported there:

http://www.amiga.org/developer/bugreports/view.php?id=816


So, at least 2 bugs to deal with minumum. + 1 about crash on exit, + if something new will arise when game's shaders will be in use.

@kas1e

...I like worms...

And, don't be mad, but I was expecting something like this, that's why I waited for you to join in.
I knew I'd never been able to pinpoint and test out weird behaviour and bugs, coming from outside of scummvm, myself.

Keep on...I'll support where I can, but unfortunately my spare time is short and my skills even more.

@Raziel
Yeah, bugs are interesting to deal with :)

Anyway, have some progress: i build latest version of scummvm on my x86/linux, and over MESA it runs all fine. Then i build also gl4es for x86/linux, and tried to run ScummVM over it instead of original MESA drivers : and know what, it's fail to compile some simple internal-test scummvm shader with preprocessor error about missing "ifs/endif", the same issue as i have on amigaos4 builds once before , and which disappear somehow in later tests, but i can see clearly that bug on x86/linux now.

In other words we have there an gl4es issue as well about shaderconversion and if/else preprocessing in. Strange that it arise with scummvm only, and that it disappear from my latest amigaos4 builds somehow magically (but that understandable - if there some bugs with stack, all kind of stuff can be changed).

I reported issue to ptitSeb and he on it for now, so once it will be fixed, i can go further and check if ARB shaders works with gl4es's ARB conversion code or not, to find out if it another GL4ES issue, or with our drivers.

@kas1e

Nice progress...thank you for the updates

@Raziel
And some more progress :

1). Issue with this preprocessor if/else/endif were fixed in gl4es (they happens before on amigaos4, then disappear magically, and now i just found it by luck on x86, which was easy to reproduce, so ptitSeb were able to deal with).

2). Issue with crash when we run in OpenGL mode happens on both, and on amigaos4, and on x86/linux when use GL4ES, so, that again, GL4ES issue on which ptitSeb works now. See for more details:

https://github.com/ptitSeb/gl4es/issues/373


After that will be fixed, all the specific amigaos4 related commits from lephilousophe from scummvm can be merged with no problems.

And so, once #2 will be fixed, it will be time to check ARB shaders for pure OpenGL, and all the original GLSL shaders coming with the games.

Quite lot of bugs at one time, but that will improve things for sure!