Broken rendering in GRIM on AmigaOS4 with all shaders disabled when GLAD were added

[kas1e]

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.

[kas1e]

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

`
3/0.Work:games/ScummVM_2_6_0_beta_2021_12_23> scummvm_glad_mgl
Using joystick: Logitech Dual Action
WARNING: SearchSet::add: archive 'gui-icons.dat' already present!
User picked target 'grim-win' (engine ID 'grim', game ID 'grim')...

Looking for a plugin supporting this target... Grim

Running Grim Fandango (Windows/English)
VOX0001.LAB: 8b12ed530195c6c577436df27df62ecb, 58011176 bytes.
WARNING: VideoTheoraPlayer::initialize - Theora support not compiled in, video will be skipped!
WARNING: Could not parse GLSL version 'Huh?'!
INFO: OpenGL Vendor: The MiniGL Team (minigl.library 2.24)
INFO: OpenGL Renderer: MiniGL/Warp3D Warp3D Nova Bridge
INFO: OpenGL Version: 1.3
INFO: OpenGL Red bits: 0
INFO: OpenGL Green bits: 0
INFO: OpenGL Blue bits: 0
INFO: OpenGL Alpha bits: 0
INFO: OpenGL Z buffer depth bits: 0
INFO: OpenGL Double Buffer: 0
INFO: OpenGL Stencil buffer bits: 8
WARNING: Could not parse GLSL version 'Huh?'!
INFO: OpenGL Vendor: The MiniGL Team (minigl.library 2.24)
INFO: OpenGL Renderer: MiniGL/Warp3D Warp3D Nova Bridge
INFO: OpenGL Version: 1.3
INFO: OpenGL Red bits: 0
INFO: OpenGL Green bits: 0
INFO: OpenGL Blue bits: 0
INFO: OpenGL Alpha bits: 0
INFO: OpenGL Z buffer depth bits: 0
INFO: OpenGL Double Buffer: 0
INFO: OpenGL Stencil buffer bits: 8
WARNING: Could not parse GLSL version 'Huh?'!
INFO: OpenGL Vendor: The MiniGL Team (minigl.library 2.24)
INFO: OpenGL Renderer: MiniGL/Warp3D Warp3D Nova Bridge
INFO: OpenGL Version: 1.3
INFO: OpenGL Red bits: 0
INFO: OpenGL Green bits: 0
INFO: OpenGL Blue bits: 0
INFO: OpenGL Alpha bits: 0
INFO: OpenGL Z buffer depth bits: 0
INFO: OpenGL Double Buffer: 0
INFO: OpenGL Stencil buffer bits: 8
WARNING: Lua_V1::SetGamma, implement opcode, level: 0.000000!
`

GL4ES compile

`
3/0.Work:games/ScummVM_2_6_0_beta_2021_12_23> scummvm_glad_gl4es
LIBGL: Initialising gl4es
LIBGL: v1.1.5 built on Feb 24 2022 17:19:22
LIBGL: Using GLES 2.0 backend
LIBGL: Using Warp3DNova.library v54 revision 13
LIBGL: Using OGLES2.library v3 revision 2
LIBGL: OGLES2 Library and Interface open successfuly
LIBGL: Targeting OpenGL 2.1
LIBGL: NPOT texture handled in hardware
LIBGL: Not trying to batch small subsequent glDrawXXXX
LIBGL: try to use VBO
LIBGL: Force texture for Attachment color0 on FBO
LIBGL: Hack to trigger a SwapBuffers when a Full Framebuffer Blit on default FBO is done
LIBGL: Current folder is:Work:games/ScummVM_2_6_0_beta_2021_12_23
LIBGL: Hardware test on current Context...
LIBGL: Hardware Full NPOT detected and used
LIBGL: Extension GL_EXT_blend_minmax detected and used
LIBGL: FBO are in core, and so used
LIBGL: PointSprite are in core, and so used
LIBGL: CubeMap are in core, and so used
LIBGL: BlendColor is in core, and so used
LIBGL: Blend Substract is in core, and so used
LIBGL: Blend Function and Equation Separation is in core, and so used
LIBGL: Texture Mirrored Repeat is in core, and so used
LIBGL: Extension GL_OES_mapbuffer detected
LIBGL: Extension GL_OES_element_index_uint detected and used
LIBGL: Extension GL_OES_packed_depth_stencil detected and used
LIBGL: Extension GL_EXT_texture_format_BGRA8888 detected and used
LIBGL: Extension GL_OES_texture_float detected and used
LIBGL: Extension GL_AOS4_texture_format_RGB332 detected
LIBGL: Extension GL_AOS4_texture_format_RGB332REV detected
LIBGL: Extension GL_AOS4_texture_format_RGBA1555REV detected and used
LIBGL: Extension GL_AOS4_texture_format_RGBA8888 detected and used
LIBGL: Extension GL_AOS4_texture_format_RGBA8888REV detected and used
LIBGL: high precision float in fragment shader available and used
LIBGL: Extension GL_EXT_frag_depth detected and used
LIBGL: Max vertex attrib: 16
LIBGL: Max texture size: 16384
LIBGL: Max Varying Vector: 32
LIBGL: Texture Units: 2/2 (hardware: 32), Max lights: 8, Max planes: 6
LIBGL: Extension GL_EXT_texture_filter_anisotropic detected and used
LIBGL: Max Anisotropic filtering: 16
LIBGL: Max Color Attachments: 1 / Draw buffers: 1
LIBGL: Hardware vendor is A-EON Technology Ltd. Written by Daniel 'Daytona675x' MьЯener @ GoldenCode.eu
LIBGL: GLSL 300 es supported
LIBGL: GLSL 310 es supported and used
Using joystick: Logitech Dual Action
WARNING: SearchSet::add: archive 'gui-icons.dat' already present!
Using joystick: Logitech Dual Action
User picked target 'grim-win' (engine ID 'grim', game ID 'grim')...

Looking for a plugin supporting this target... Grim

Running Grim Fandango (Windows/English)
VOX0001.LAB: 8b12ed530195c6c577436df27df62ecb, 58011176 bytes.
WARNING: VideoTheoraPlayer::initialize - Theora support not compiled in, video will be skipped!
INFO: OpenGL Vendor: ptitSeb
INFO: OpenGL Renderer: GL4ES wrapper
INFO: OpenGL Version: 2.1 gl4es wrapper 1.1.5
INFO: OpenGL Red bits: 8
INFO: OpenGL Green bits: 8
INFO: OpenGL Blue bits: 8
INFO: OpenGL Alpha bits: 8
INFO: OpenGL Z buffer depth bits: 24
INFO: OpenGL Double Buffer: 1
INFO: OpenGL Stencil buffer bits: 8
INFO: OpenGL Vendor: ptitSeb
INFO: OpenGL Renderer: GL4ES wrapper
INFO: OpenGL Version: 2.1 gl4es wrapper 1.1.5
INFO: OpenGL Red bits: 8
INFO: OpenGL Green bits: 8
INFO: OpenGL Blue bits: 8
INFO: OpenGL Alpha bits: 8
INFO: OpenGL Z buffer depth bits: 24
INFO: OpenGL Double Buffer: 1
INFO: OpenGL Stencil buffer bits: 8
INFO: OpenGL Vendor: ptitSeb
INFO: OpenGL Renderer: GL4ES wrapper
INFO: OpenGL Version: 2.1 gl4es wrapper 1.1.5
INFO: OpenGL Red bits: 8
INFO: OpenGL Green bits: 8
INFO: OpenGL Blue bits: 8
INFO: OpenGL Alpha bits: 8
INFO: OpenGL Z buffer depth bits: 24
INFO: OpenGL Double Buffer: 1
INFO: OpenGL Stencil buffer bits: 8
WARNING: Lua_V1::SetGamma, implement opcode, level: 0.000000!
`

[lephilousophe]

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.

[kas1e]

@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.

[kas1e]

@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.

[kas1e]

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.