Opened 3 years ago
Closed 3 years ago
#13351 closed defect (fixed)
Broken rendering in GRIM on AmigaOS4 with all shaders disabled when GLAD were added
Reported by: | kas1e | Owned by: | kas1e |
---|---|---|---|
Priority: | normal | Component: | Graphics |
Version: | Keywords: | GLAD, amigaos4, Grim | |
Cc: | kas1e | Game: | Grim Fandango |
Description
We found that right after this commit: https://github.com/scummvm/scummvm/commit/21b0d6ded18e6994e43c316759e4ffdb487f244d (i.e. when GLEW were replaced with GLAD, and co) , rendering in GRIM game even with pure OpenGL (so everything build with --disable-opengl-game-shaders) start to produce wrong result.
That how it in previous to GLAD merge commit looks like:
start:
in menu (when hit f1):
Now, once we update to GLAD, that what we have:
At start (see no person rendered anymore):
In the menu (see, no sprites rendered at all):
That all happens when i build it all with GL4ES (which use ogles2.library, to translate GL 2.1 calls to ogles2). I will try with MiniGL as well, but main point that it works before GLAD, and stop works after. So we probably just unhide some bug somewhere.
Change History (6)
comment:2 by , 3 years ago
Owner: | set to |
---|---|
Resolution: | → pending |
Status: | new → pending |
Maybe aquadran you could diagnose what's wrong with this?
I don't see what GLAD would introduce wrong? It's like it would hook the function or something like that.
comment:3 by , 3 years ago
@All
Thanks to lephilousophe , we find out some important details about this issue.
For first, when we build things before GLAD were added, i had to add to engines/grim/gfx_opengl.cpp that :
#undef GL_ARB_fragment_program
Because without, i can't build GRIM's opengl code with GL4ES, as it were screaming about cross-redefination in the game's engine code and in gl4es itself.
So, that mean we disable GL_ARB_fragment_program and it works, and create internal gl4es shaders without ARB extensions.
Now, when we switch to GLAD, no errors with compiling happens anymore, and GL_ARB_fragment_program are enabled now, and such, we have new internal gl4es shader of this kind:
#version 100 #extension GL_EXT_frag_depth : enable precision highp float; precision highp int; varying mediump vec4 _gl4es_TexCoord_0; uniform sampler2D _gl4es_Sampler2D_0; void main() { vec4 gl4es_FragDepthTemp = vec4(gl_FragDepthEXT); vec4 d; d = texture2D(_gl4es_Sampler2D_0, _gl4es_TexCoord_0.xy); gl4es_FragDepthTemp = d.xxxx; gl_FragDepthEXT = gl4es_FragDepthTemp.z; }
and
#version 100 precision highp float; precision highp int; varying mediump vec4 _gl4es_TexCoord_0; uniform vec4 _gl4es_Fragment_ProgramLocal_0; uniform sampler2D _gl4es_Sampler2D_0; void main() { vec4 level = _gl4es_Fragment_ProgramLocal_0; vec4 color; vec4 d; vec4 sum; d = texture2D(_gl4es_Sampler2D_0, _gl4es_TexCoord_0.xy); sum = d.xxxx; sum = sum + d.yyyy; sum = sum + d.zzzz; sum = sum * vec4(0.330000, 0.330000, 0.330000, 0.330000); sum = sum * level.xxxx; gl_FragColor.x = sum.x; gl_FragColor.y = sum.y; gl_FragColor.z = sum.z; }
And so, with those new shaders, things not renders properly and reacts as they reacts.
To be 100% sure that this is the issue, we just set to gl4es to not use ARB progamms at all, like LIBGL_NOARBPROGRAM 1 and it start to works again, and make no those 2 new shaders.
And now, question is: what and where wrong. It can be or gl4es , or something in our OGLES2 on AmigaOS4. Pure test cases with ARB programms compiled over gl4es (such as for example SDL2's "testshader.c" ) works fine, so it can be issue with GL_EXT_frag_depth extension which is used in new shaders once ARB programs in use.
So that need some checks/tests on our sides , but at least we know the roots for now.
Just let the topic be until we not fix it all.
comment:4 by , 3 years ago
@All
It turns out that GL4ES on X86/Linux have exactly the same issue, meaning that problem is on the GL4ES side.
Let the issue be open for a little bit longer, and once it will be fixed i can close it.
comment:5 by , 3 years ago
As were found issue was a mixture of the problems. Some of the was in scummvm (lights channels), some in OGLES2 (mirrored textures when use FBO and wrong colors when use VBO), and some in gl4es (ARB shader depth related)
All of them were taken care off except the ARB shader issue in GL4ES, but as we on amigaos4 will use now or MiniGL or OGLES2 directy (and GL4ES works over OGLES2), so we have no needs to worry about GL4ES for scummvm.
comment:6 by , 3 years ago
Owner: | changed from | to
---|---|
Resolution: | pending → fixed |
Status: | pending → closed |
Additional info : Linking against MiniGL make it works again ! So , that issue when we use GL4ES wrapper working via ogles2.
The differences as i see on running are:
MiniGL compile
GL4ES compile
TO note : i just change pure link libraries, include files all stays the same be it minigl build or gl4es build.
Question : Is all ok on other platforms in that terms ?