On 3rd comment you can see what we found: once we use GL_ARB_fragment_program, GL4ES also tried to use GL_EXT_frag_depth if available, and so create 2 additional internal shaders:
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;
}
Now, with those 2 shaders added, things start renders bad and wrong. When there is no those 2 shaders, then all renders fine.
I even tried simple to do "setenv LIBGL_NOARBPROGRAM 1", and everything fixes, as no more those 2 shaders created.
Now, question, what do we can do next and how to test functionality of things involved in those 2 shaders ? As GL_ARB_fragment_program somehow works at least, i think it can be something about GL_EXT_frag_depth , but have anyone any idea how to test it , etc?
I for myself think of disabling GL_EXT_frag_depth extensions usage inside of the GL4ES, so to see if it is which is guilty.
Have you tried to modify those shaders, for example hardcode some values? What happens if you change gl_FragColor.w (alpha channel) to 1.0 in the latter? It doesn't seem to be initialized.
It would be interesting to know also what is passed via _gl4es_Fragment_ProgramLocal_0 uniform. glSnoop should be able to show that.
Have you tried to modify those shaders, for example hardcode some values? What happens if you change gl_FragColor.w (alpha channel) to 1.0 in the latter? It doesn't seem to be initialized.
Only tried so far to remove "#extension GL_EXT_frag_depth : enable" from shader, and that make no differences for bug.
Will test other stuff you suggest
Quote:
It would be interesting to know also what is passed via _gl4es_Fragment_ProgramLocal_0 uniform. glSnoop should be able to show that.
There is a full ogles2 trace (without warp3dnova calls, to avoid unnecessary stuff for now) from glsnoop when i run scummvm, choose a game, and exit from:
It would be interesting to know also what is passed via _gl4es_Fragment_ProgramLocal_0 uniform. glSnoop should be able to show that.
Rechecked logs myself, and not sure if glsnoop show us anything interesting about ?
I also do for now that:
I tried to just comment out S("GL_EXT_frag_depth ", fragdepth, 1); in hardtex.c of GL4ES, so LIBGL didn't use now that extension, and while i still have rendering problem, shaders now looks like this:
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;
}
See, first one changes : it not didn't use Depth Frag extension, but instead some "fakeddepth" , but bug still here.
So it probabaly safe to assume now, that issue not because of extension, and it probably a second shader.
But with second shader i have a hard time to understand from where it come. I tried to search in the whole ScummVM sources on the words "sum" , or on "vec4 d" , and in ScummVM found a shit about. But then i also found notihng about in GL4ES too! Wtf, from where that second shader come then ?
It should be from ScummVM imho, some kind of ARB shader generator, just i can't find where.
@Capehill I think i found from where that new ARB shader code : from ScummVM, in the GRIM's code. There are 2 arb shaders, but they are in some strange-for-me-mnemonic-format, see:
d = texture2D(gl_Sampler2D_0, gl_TexCoord[0].xy);
sum = d.xxxx;
sum = sum + d.yyyy;
sum = sum + d.zzzz;
sum = sum * vec4(0.33, 0.33, 0.33, 0.33);
sum = sum * level.xxxx;
gl_FragColor.x = sum.x;
gl_FragColor.y = sum.y;
gl_FragColor.z = sum.z;
}
And then gl4es add a bit of changes on top for internal needs to have it works on ogles2.
Was there some different GLSL kind language back in days for ARB shaders ?
Anyway, i added to that "strange" shader "MOV result.color.a, 1.0;\n\" at end, and so consructred shader looks like this:
The fact, that when we disable ARB shaders via "LIBGL_NOARBPROGRAM 1" and have all works, make me think that maybe ARB shader generator in GL4ES not works as expected and have bugs (or, which is more lucky, it didn't have bugs, but we do have on ogles2/warp3dnova front)
EDIT: oh, find out, ARB shaders was pre-GLSL language which were ditch later. I just messed things a bit with our SDL2 testshaders.c case , as while it use ARB extensions, the shaders it use are of GLSL format, and not of original-oldshcool ARB one while in GRIM-ScummVM those ARB shaders are real oldschool ones.
Edited by kas1e on 2022/3/15 17:00:23 Edited by kas1e on 2022/3/15 17:01:07
It turns out that the same issue happens on GL4ES on X86/Linux, so, nothing for us to worry about for the moment as this probably will be fixed inside of GL4ES.
@Capehill Turned out that this issues (with bad rendering of person) and with main hero overwrite some parts of screen can't be fixed easyly:
The main problem is that pixel conversion function (gl4es_glDrawPixel() ) doesn't handle depth component at all. But ptitSeb says that:
Quote:
Problem is on gles hardware, we cannot do most of the things we can do on full opengl hardware with depth buffer (and stencil buffer). I remember, back when residual was independant from scummvm, that I needed to hack the opengl code to get correct rendering of the caracters, because the operation done by on the engine on the depth buffer were just not supported on the gles2 hardware of the Pandora.
But the glDrawPixel(...) on depth or stencil, well, I don't know how to do that with gles2 hardware...
That turns out to be non fixable seems ? At least only by rewriting parts of game's code to not use depth or something..
Instead , we then better to go pure OGLES2 route which scummvm support as well, and fix issues in OGLES2 (or in shaders if Daniel/Hans will have no interest about), and just not use GL4ES for ScummVM.
But then , Pure OGLES2 build have some issues too (meaning no GL4ES usage, just pure olges2). See the video:
There isn't much shaders from all those in use when Manny is drawn. By using glSnoop (damn how good we have that), i find out that those shaders are loaded up when we run game:
the texZBuf it's a special texture because it's internalformat is GL_LUMINANCE_ALPHA. so it has two channels and we load it raw data. then when you look at the shader, you load r and a, as x and y, and then you do basically a load to make them read like a short (on a range from 0 to 1 instead of 0 to 655536).
So i just switch sampled.y and sampled.x and this helped much, then i also uncomment in shaders #define SGSPLUS_FIX, but not with offsetY 32, but with 0.0. And that fix all issue.
In end it looks like that:
1). scummvm shaders should be fixed for x/y stuff, so bug in shaders.
2). it seems ogles2 doees not do flipping as all OpenGL surfaces should be ? I.e. there problem with top/down.
But hope tomorrow we will find more about. But at least we make it works ! And i have sometime up to 200 FPS ! See:
Edited by kas1e on 2022/3/20 22:02:58 Edited by kas1e on 2022/3/20 22:04:35 Edited by kas1e on 2022/3/20 22:05:27 Edited by kas1e on 2022/3/20 22:05:54 Edited by kas1e on 2022/3/20 22:29:35 Edited by kas1e on 2022/3/20 22:32:24 Edited by kas1e on 2022/3/20 23:09:35 Edited by kas1e on 2022/3/20 23:10:16
I didn't understand quite this issue. aglSwapBuffers() not working?
There some strange issue we found, which seems ogles2 related, but we didn't sure at moment (one of scummvms coders still trying to made a test case for). The issue is about vertical flips of depth with textures , which seems should happens automatically on all opengl realisations (at least, it seems so on Mesa and Odroid).
I.e. we have a person , which just overwrite by his own rendering the parts at bottom which he should. We think before that nothing works, but, we found that "depth" coordinates just AT TOP of scene, while should be at the bottom.
He still trying to create test case, because he fear he can be wrong, so can't explain normally issue. But i can say that thing is: we have that issue and on direct OGLES2, and via GL4ES, which can point that roots come from OGLES2/Nova/whatever. s
We do fix thos "top-down flipped depth" issue it in grim_actor and grim_actorlight shaders like this:
changing 1.0-(gl_FragCoord.y-0.5)/screenSize.y to (gl_FragCoord.y-0.5)/screenSize.y
So because of that we make an opinion that "texture with depth" , or "depth for texture" is not flipped as texture itself while should.
But important moment :
We don't use depth textures in GL with shaders as it, we use GL_LUMINANCE_ALPHA for depth there.
So issue can be that unpopular GL_LUMINANCE_ALPHA for example as well.
I.e. all we know for now (without test case at the moment), is that :
1. The texture2D (in the code we use texture but there is a define in the code which says that texture is texture2D) is used everywhere, so this function seems to work for classic textures
2. we don't use depth textures in GL with shaders, we use GL_LUMINANCE_ALPHA.
3. So what OpenGL says is that when you create such texture and fill it, it's like all the others except that R G and B are equals (to luminance) and A is set to A. Then when you read in the shader it must work like all other textures.
But in our case it doesn't seem to work. So maybe there is a bug in OGLES2 when handling GL_LUMINANCE_ALPHA textures.
Maybe problem happens because our GLES2 implementation don't support DEPTH with 16 bits of precision.
If you have any idea about, plz feel free :) Maybe you even may have some tests cases about GL_LUMINANCE_ALPHA textures , etc showing that all works/not works as expected ?
I see it was fixed long ago, but do you think it's related ?
Quote:
Have you asked Hans about this yet?
Nope, not at moment, we firstly need to create test case, to be 100% sure how to reproduce it, because without simple test cases no one will fix anything :)
Maybe problem happens because our GLES2 implementation don't support DEPTH with 16 bits of precision.
From OGLES2 documentation: "OGLES2_CCT_DEPTH (uint32 ZBufferDepth) Desired z-buffer bit-depth (e.g. 16) or 0 if you don't need a z-buffer."
You can check what is passed in during GL context creation.
Quote:
I see it was fixed long ago, but do you think it's related
Not necessarily but symptom sounds similar, so maybe it can be at least ruled out. Sounds like texture format shouldn't matter but how about target texture scenario (FBO)?
I had my own issue with FBOs (flipped Y) but I haven't written a portable example to check it on Linux.
I had my own issue with FBOs (flipped Y) but I haven't written a portable example to check it on Linux.
Ha so flipped Y are not new problem then .. At least in your tests too. And we probably use FBO there too .. Maybe i need to try to disable FBO to see how it will be without
Then no problems ! All works fine, and no flip by Y all fine !
So , it very much looks like issue you had is the same we had in scummvm now.
It's time to made a test case for sure, because it definately bug somewhere in nova/ogles then.
And in case with Scummvm we can't just disable FBO for release because it mean no resizing of the window mode when we use Grim , monkey4 , etc (as those engines do not have internal resizing, so FBO is only way to have it).
In what condition you have this issue btw ? I mean, in some game or when code shaderjoy ?
Rigth.. But now ScummVM shows that issue is probabaly not your code, but there seems some problem indeed in ogles2/nova. We just need test case now. ScummVM's dev says he may have time tomorrow/etc and to try to create test case..
But what cleary is : it's surely FBO related only. Without FBO we have no such problem.
@Capehill I start to fear that scummvm's dev who helped us may have no time again, maybe we can somehow create a test case without asking him for help ?
At least we know that issue is "textures with FBO" , so maybe we can try to at least create SDL2 based example which works over ogles2 and load up texture, enable FBO and show it up ? Maybe that will be enough ?
Or shaders should have take the place in any case there ?
// Store the test program object
userData->testProg = LinkProgram(vShaderStr, fShaderStr);
if (userData->testProg == 0) {
return GL_FALSE;
}
// Store the alternate test program object
userData->testAltProg = LinkProgram(vShaderAltStr, fShaderAltStr);
if (userData->testAltProg == 0) {
return GL_FALSE;
}
// Store the drawing program object
userData->drawProg = LinkProgram(vDrawTexStr, fDrawTexStr);
if (userData->drawProg == 0) {
return GL_FALSE;
}
// Store the alternate drawing program object
userData->drawAltProg = LinkProgram(vDrawTexAltStr, fDrawTexAltStr);
if (userData->drawAltProg == 0) {
return GL_FALSE;
}
// For EGL on X11 to use with RenderDoc
#ifdef SDL_VIDEO_DRIVER_X11
SDL_SetHint(SDL_HINT_VIDEO_X11_FORCE_EGL, "1");
SDL_SetHint(SDL_HINT_OPENGL_ES_DRIVER, "1");
#endif
- when displaying test texture (black and white), change the display method with key <d>
As can be seen we can reproduce issue and we fail when
1. FBO is enabled, in mode 1 (red triangle will be displayed instead of green square)
2. FBO is enabled, and in mode 2 with alternate display (using gl_FragCoord, black will be below and white above).
To sum up:
When enabling FBO, gl_FragCoord begins to act up reversed with 0.0 at top and 1.0 at bottom instead of the usual 0.0 at bottom.
Now, what issue is ? Ogles2 or Nova ? At least reading your with Daniel discussion back in time about, it seems that it can be Ogles2 issue ?
At least we can create it for ogles2 for a start and if things turns out to Nova we can change the ticket ..
---------------
Anyway, while it's now clear that isues in our drivers and should be fixed there, i want to find out what issues are with the last problematic shaders in scummvm : shaders for "Escape From Monkey Island".
Issue we have there, that all "actors" renders black, see:
Shaders with name "emi_*" at begining are for that game.
So, background, dimplane and sprite ones are out of question (because we can see on video that background, planes and sprites on image renders correctly).
Issue is 2 pairs: emi_actor and emi_actorlights. As it issues with colors, it mean fragment shaders then. So we end up with issue (or bug on our side) being there:
Can you se anything wrong there ? It can be easy something unitialized or so ...
ps. if you watch video more, you can see on 0:29, that main hero got the color at some point. Mean that things can works, just something wrong somewhere ..
Edited by kas1e on 2022/3/27 21:02:24 Edited by kas1e on 2022/3/27 21:17:15 Edited by kas1e on 2022/3/27 21:20:08
Now, what issue is ? Ogles2 or Nova ? At least reading your with Daniel discussion back in time about, it seems that it can be Ogles2 issue ?
At least we can create it for ogles2 for a start and if things turns out to Nova we can change the ticket ..
My guess is that problem is in Nova, but we can only compare OpenGL test apps between operating systems. It would be good to hear Daniel's opinion first because he was suspecting application issue (wrong UV coords) earlier but now it seems issue is somewhere on the library side, thanks to your tests.