[Scummvm-tracker] [ScummVM :: Bugs] #13351: Broken rendering in GRIM on AmigaOS4 with all shaders disabled when GLAD were added

ScummVM :: Bugs trac at scummvm.org
Mon Mar 14 15:09:54 UTC 2022


#13351: Broken rendering in GRIM on AmigaOS4 with all shaders disabled when GLAD
were added
---------------------------------+----------------------------
Reporter:  kas1e                 |       Owner:  aquadran
    Type:  defect                |      Status:  pending
Priority:  normal                |   Component:  Graphics
 Version:                        |  Resolution:  pending
Keywords:  GLAD, amigaos4, Grim  |        Game:  Grim Fandango
---------------------------------+----------------------------
Comment (by 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.
-- 
Ticket URL: <https://bugs.scummvm.org/ticket/13351#comment:3>
ScummVM :: Bugs <https://bugs.scummvm.org>
ScummVM


More information about the Scummvm-tracker mailing list