gl4es and ScummVM #366
Comments
|
Hm, i set to dump all the shaders to log (LIBGL_DBGSHADERCONV to 15), and that is what i have: And new shadersource are: Not sure that i understand what happens, at least i can see that original have all correct ifdefs, then, second shader (dunno by which created ? By gl4es ? ) didn't have all those ifs , so of course fails. Through as i remember all shaders created by gl4es should have gl4es_ marks at beginning of shader's calls, but this one looks strange .. Isn't it gl4es convert the original shader to something before making "gl4es" ones? |
|
Hi @kas1e . Yes, that looks like a bug in the Shaderconv. In the précompte part to be precise. |
|
Howdy !:) Tried workaround: nope didn't help. The same can't compile shader and error about missing ifdef. and white rectangle on-screen. Btw i also have errors on lining stage about multiple definitions of some ARB functions: For all of them says that they were defined n lbgl4es's oldprogram.c. Scummvm code from other side contains that : |
|
Another moment that if i just do that: i.e comment out all those ifs/else then while all compiles well but I have a black screen and nothing else. The shaders they use are there: https://github.com/scummvm/scummvm/blob/master/backends/graphics/opengl/shader.cpp See there g_defaultVertexShader g_defaultFragmentShader g_lookUpFragmentShader and that g_precisionDefines. |
|
renderer set to ex: |
|
@arrowgent |
|
what version of scummvm and gl4es are you using? I tried with latest gl4es using debian version of scummvm and I add no issues, the shaders converted correctly for me. |
|
I use gl4es-master commit 2484 And 5 days old ScummVM build from their auto-build repo. Will try latest gl4es now |
|
Tried latest version cant compile: |
|
Ok, this one should be fixed (there may be some more after that) |
|
At least it fully compiles now thans! I will check scummvm now |
|
@ptitSeb Through they happen to be just for one game so can comment them out. |
|
@ptitSeb |
|
Happens because of that shader https://github.com/scummvm/scummvm/blob/master/backends/graphics/opengl/shader.cpp#L81 |
|
if i short that code to version without ifs/endifs lie: Then on running i have that: |
Yes, it's a problem because the symbol are exported by gl4es, just in case, and scummvm defined them also (probably some function pointer with the same name). With a dynamic linking, this kind of issue doesn't happens, so yeah, maybe just comment them for now, I don't see any easy fix, instead some mangling of the exported name, but then they will have to be mangled also to use them... |
|
Here is the last shader, using DEBUGSHADERCONV, when launching just the GUI (I haven't setup any game) As you can see, the original have all the ifdef, and they get converted corretly by shaderconv (using default settings) |
|
And here, using Again, it converted properly. |
|
Hm.. and what can it mean then... Shaderconv's endian or amigaos4 specific issues? |
|
Not sure. Shaderconv should not be really sensitive to endianness, as it only char manipulation. |
|
now rebuild from scratch everything deleted .gl4es.psa and run again: same error. Lie something weird happens only on my side when shaderconv meet with those "ifs/elses". |
|
this will happens in "preproc.c". Try to put some |
|
Aha will try now. Also what is interesting if modify that shader to not have ifdefs then stll have this error: WARNNG: GL_ERROR: GL_NVALD_ENUM on glGetProgrammv(_program, 0x8b82, &result) (backends/graphics/opengl/shader.cpp:170) i tried to compile all shaders manually and they fine.. Somethng weird .. |
|
@ptitSeb So by if/else/endif you mean strings from 464 till 500 in the preproc.c that correct? What i miss in the new shader after shaderconv is that : i.e. all after a second else whole buffer part together with else disappear. Lie too small buffer or something .. or some NULL arse from nowhere and split end the buffer in the middle. |
|
from 460 to 588 (it's a state automate). |
|
@ptitSeb So, there are the file they generated (do not know via command line tool, or just by own GLAD's site there : https://glad.dav1d.de/), but that what they have now in scummvm repo: Now, what issue we have now. If i build ScummVM via GL4ES withut usage of the shaders coming with GL4ES (so only internal ones from gl4es are used), before they add GLAD support, everything renders correctly. See for example Grim Farnando game: at start: https://kas1e.mikendezign.com/aos4/scummvm/grim_bug/01_before_glad_grim_start.jpg in the menu: https://kas1e.mikendezign.com/aos4/scummvm/grim_bug/02_before_glad_grim_menu.jpg Now, once they this commit (where they add GLAD instead): That what i have when i build it with GL4ES: at start: https://kas1e.mikendezign.com/aos4/scummvm/grim_bug/01_after_glad_grim_start.jpg in the menu: https://kas1e.mikendezign.com/aos4/scummvm/grim_bug/02_after_glad_grim_menu.jpg See, now there is no main person rendered anymore, and in the menu, we have no sprites at all. Now, when i compile exactly the same over MiniGL , we do not have this problem. Everything renders correctly and with pre-GLAD addon, and affter GLAD too. I even use exactly the same GL includes from GL4ES for both minigl and gl4es builds. Just once i link scummvm with GL4ES, then after this "GLAD" change i have no main person rendered and sprites missed. I know, this again will be problem on our side (i am pretty sure it will), but you may at least bring some idea to what to check, etc. Maybe you will notice something "bad" right from the start.. So far i thinking for now about just dumping all the GL4ES internal shaders with pre-GLAD change version, and with-GLAD change version, to compare, if anything changes. If you have time, you may try also to build latest scummvm sources (those from github ones, not a stable ones) to see how it reacts on Pandora, so we can rule out GL4ES bug/difference. But something make me think it will be bug on our side, again :) |
|
@ptitSeb I create ticket on their site : https://bugs.scummvm.org/ticket/13351 , maybe you have anything to add about. And still interesting moment, is that MiniGL build surely works with GLAD (i use exactly the same includes for both builds, just for MiniGL build i use -lSDL2 -lgl on linking, and for gl4es one -lSDL2_gl42s -lgl4es). So it should't be something about includes per se. |
|
I suppose GLAD find something wrong when it check what extensions are availlable or not, and disable some of it for some reasons. I'll check on the pandora/pyra later. |
|
Yeah, it should be something like this indeed.. For sake of tests, i tried to build two versions (pre-glad and right-after-glad) and dump internal gl4es shaders (to see, if there will be any difference), and yeah, i can see the difference. There is one before glad added: There is one after glad added: I can see that shaders changes indeed. And changed very much ! Start checking from line 600. The just really different, and not only that, but i can see that #extension GL_EXT_frag_depth : enable are added after glad too. But ok, i can understand it only that extensions were now added, but why shaders changes that much ? Seems GLAD really change the way how to compile internal shaders. |
|
Oh, now we understand it better. Problem is usage of the GL_ARB_fragment_program. Before, everything works, because i had to add to GRIM's game code that: #undef GL_ARB_fragment_program Or it wasn't compiled as cause cross-references with the ARB functions names from gl4es. So i disable it before, and all works and compiles. Now, when we swithc to GLAD, all compiles fine, and GL_ARB_fragment_programm start to be in use. And thuse, create new shaders (with that GL_EXT_frag_depth usage), and they just fail by some reassons. It is expected that when ARB programms in use, then we have those new shaders which tried to use GL_EXT_frag_depth ? I feel issue can be on our side again, or about ARB extension, or, what is more luckyly GL_EXT_frag_depth usage together with GL_ARB_fragment_program. |
|
Mmm, so more bugs in the ARB program parser I guess... About the "includes". THose are just regular "GL" and co. include file. Not really from gl4es project. I don't really handle them, and you can switch to some better version if you want. |
Not necesasary, as always it can be on our side :) So far i tred in the shaderconv.c to change And See while first shader without this Just want to check if it extensions cause issues or not. EDIT: lephilousophe says it's fragdepth because there is |
|
The |
|
What i mean, is that i want to try to disable this extension at all from gl4es, to see what shaders will be created then when ARB used, and will it works or not (that can point out us to some direction maybe) |
|
@ptitSeb and And bug still here. So even without usage of GL_EXT_frag_depth but instead with usage of faked one, we still have there such rendering error. Capehill suggest to try to "hardcore" some values for tests, for example he suggest ti change gl_FragColor.w (alpha channel) to 1.0 in the latter shader as It doesn't seem to be initialized, will check it. |
|
By the way, can you also plz explain how things works with ARB parser too , is that second shader created by I just need it to understand where to put gl_FragColor.w = 1.0; inside of GL4ES, so to see if it can be what Capehill suggest or not. |
|
ps. there is some nitpicking about LIBGL_DBGSHADERCONV - there missing |
|
Ok we find out : that shaders come from GRIM's game code of ScummVM: And see, it in some strange format: I am thinking before, that ARB shaders use GLSL syntax (and in example from SDL2, they are), but there its like some old-school assembler kind mnemonics, and it didn't looks very well like GLSL. So ScummVM send those to GL4ES, and GL4ES translate that "old shader language" to the GLSL shaders , and then at top add shaderconversion for gl4es needs. Anyway, i add to that shader: But it didn't fix rendering at all, same visuall error. So very much looks like issue with ARB shaders, through unclear where at the moment : ogles2/warp3dnova or gl4es. |
|
It's gl4es that's translate ARB shaders to GLSL shaders. That process may still be a bit buggy sometimes. |
|
Ah, missing the ".a" write on output color? Strange it has to be added, not sure how it's supposed to behave. |
|
no no, it not fix things, its me tries to add it, because we were in hope that it will fix issues , as .a seems to be unitialized |
|
I think we there have one of two issues : or ARB shader generation from this old shader format to GLSL convert that shader somehow bad, or, which more luckyly, shader compiled correct, but fail to works on our side by some reassons (through strange why, they so small, and we test much more bigger shaders before and they works) |
|
I still need to build scummvm on the pyra to check how it runs there. |
|
Yeah, that will rule out (or not) GL4ES at least. Basically those 2 ARB shaders looks simple enough imho, strange why they fail. But yeah i didn't test before any ARB shaders with GL4ES, i only tested ARB extensions , etc, but they all used GLSL shaders in, not that oldschool ARB ones.. Interesting, if irrlicht engine when use ARB shaders use "real" ARB shaders, and not ARB extensions with GLSL shaders .. |
|
@ptitSeb And that what i have in output: And no proper rendering. That remind me of issue about i say in that topic some posts ago (remember all those missing "ifs" , etc). Feels the same. Have any clue where to check next ? But at least it feels like this issue about "unterminated ifs" are coming from GL4ES, just by some luck i didn't have them now on amigaos4, but have on x86 Linux. But i can be wrong of course. But the fact it bring such error on x86/linux rule out amiga which is kind of relief. After it will works i can check if ARBshaders works or not too. |
|
Yes,that unterminated #if is a gl4es issue. Do you have the converted shader from the example above? |
|
Yeah, there is it: See, its the same 1:1 as i have in previous report on amigaos4 builds : #endif disappeared after shadercov. |
|
Interesting that on latest/todays amigaos4 builds i didn't have that issue, what make me think it some memory related issue, which appears/disappears in different memory-state-conditions, etc |
|
And |
|
And it not just missing endif, but whole this block: Like something happens with logic of ifdefs/if/ednifs parsing, but then we have much more heavier shaders parsed with tons of different ifdefs blocks. And bug seems to be depend on the memory layout (as i have this bug before on amigaos4 , but didn't have now, while on linux can easy reproduce it) so that not simple broken logic of if/endif/else logic parse, but IMHO something with memory ? |
|
interesting that this topic were created exactly because of that bug we discuss now and i read few posts after first one that you do test on Pandora and have no issues. The same as i didn't have issues now on amigaos4 but do have on x86/linux. Which again point out on the memory-states/changes issues. Some overflow somewhere, or out of bounds, or that kind of things. But maybe with newer scummvm you can reproduce it too.. There are the version i tried to build on x86/linux: https://github.com/lephilousophe/scummvm/archive/refs/heads/amigaos4.zip (that called amigaos4 because there some aos4 ifdefs around but that made no difference on x86 so just we both will test the same version on Pandora / Pyra / Linux. For now i can try to put printfs in "preproc.c" on the #if /#else/#endif handling to see how it goes on the lines between 460 and 588 as you suggest few posts back , but what exactly printf and where ? EDiT : btw on line 469 see this: Maybe that somehow mess around when we find this and then next ifs/else/endif fail to logic bug ? But then it should happens everywhere while you say on Pyra you don't have it before and i don't have it on AOS4 now too. At least our shader have |
|
I'm building Scummvm on the pyra. Do I need Grim Fandago to reproduce or any supported game will do? |
|
As far as i can tell, all you need is just once you run scummvm as it (wthout any game) go to "global" and choose there "graphc mode : opengl" (the top settngs not bottom one). it will mean swith main scummvm confg window to opengl mode too and you will meet with this issue |
…contained a version marquer (shoudl help #366 and other)
|
Ok, it should be fixed now. At least it seems to works on the Pyra now. |
|
Yeah! That bug gone for sure now ! Thanks a bunch! Next, when i tried to run GRIM Fardango with "OpenGL" 3D renderer set in options of ScummVM, then when i run it over MESA all fine, but when i run it over GL4ES, i have that: I also can see, that those ARB shaders created as well, and also gl_FragDepthExt is used, so from that side all ok. But then, i didn't have such crash on amigaos4 for sure, but do have there, on linux/x86. But maybe that the same reason of issue ? I mean maybe on OS4 we lucky to not crash but just have broken rendering but on Linux do crash ? |
|
This ticket is soo big, and contains so many things, I don't know what is this still to fix or not to fix. I close this ticket (I should have fixed the GL_UNSIGNED_INT issue). Please open 1 ticket per issue. |
Hi ptitSeb !
Today tried to port ScummVM over gl4es, and have some interesting issues: All initialization happens to be fine, and then:
An interesting moment is that when i build it under MiniGL ( OpenGL 1.3) , it didn't ask for any shaders, and runs fine. But once i just switch to gl4es (without any changes, just as i do all the time), it starts to try to compile some shaders from their internal ScummVM's code.
I think that maybe if they find that OpenGL is anything more than 2.0, then they trying to compile some default base shader, which by some luck didn't work (maybe because they put version 100 or something ? but then, GL4ES should make its own shaders, right ?)
If you have any ideas, feel free plz :) Or at least from where start to debug those things. Thanks!
The text was updated successfully, but these errors were encountered: