So it's actually three of the 6 skybox faces that are missing. Interesting...
Any chance you can get us the vertex shader code?
EDIT: Just looked at the Lugaru skybox code again, and I still don't see how a shader calculation bug could cause that. Each of the missing quads shares vertex coordiates with two of the visible quads.
@Hans Yeah, will dump all shaders too, just tring to reduce it even more.
Also glcalls related to the skybox can be also not only in skybox.cpp, i mean, in the GLSceneDraw(), skybox.draw called just one time, but before and after there lots of other glcalls , i.e.:
Will try to reduce it even more now, and dump all the shaders. (today ptitSeb add another ENV variable to gl4es, which make it easy to dump shaders, without needs to hack the code all the time with prinfs).
EDIT: and what is interesting, if checking carefull gl4es version video, then you can see that when we only run, some faces have copy of the previous screen (the same, as we have in RCTW Reboorn as well). I.e. chances are high that it the same issue.
1) Starting in window mode makes mouse cursor break (starting in fullscreen does not break the mouse, but ... see below) 2) Starting a game that opens it's own UI box, before going into the game itself, makes the background go nuts (not erased, should be black normally), instead it takes something from an earlier adress (it seems/i think/i believe) 2.1) If i click cancel in that box to return to the launcher/list screen, the mouse is now broken as well. (see 1)
Switching to fullscreen or back to window will "fix" the cursor. I think i know why the cursor in fullscreen is initially fine. It's because even if i start in fullscreen a window (filled black) is drawn first before it opens the screen. This window to fullscreen switch is sufficient to "fix" the cursor in initial fullscreen
@Raziel Lovely! On second screenshot you have what i have with letterfall3 game. Hans trying to fix that problem, and it was fixed, but still i have some kind of same issue somewhere (i just didnt report it at moment as worring with other ones at moment more important).
But at least in your case gl4es is not used, so or warp3d or ogles
Also what version of warp3dnova you use ? 1.58 ? Just dont remember in which one Hans fix it.
And trashed cursor probably come from sdl code, and not related to ogles2/nova
Edited by kas1e on 2019/3/26 14:42:48 Edited by kas1e on 2019/3/26 19:36:42
I would like to see a pure OpenGL ES 2.0 thread. This thread should be about GL4ES wrapper, based on its title :)
About ScummVM cursor: no, it doesn't seem SDL issue. ScummVM doesn't call SDL_SetCursor (except once for openpandora). There was a recent MiniGL fix for another ScummVM cursor issue recently (glTexImage2D).
Also after seeing a last video, ptitSeb says that it's clearly not a "negative coordinates" effect, because the missing sides are in front of each other.
And i also add glClear(GL_COLOR_BUFFER_BIT); right before skybox.draw(); call, so to see everything correctly, and that how it looks like:
2). If i uncomment any of the upcoming sides (4st or 5st or 6st) it always places on the place of the previous side. I.e. on the wrong place of the previous side.
there video when first 4 sides uncommented (can be seen how on 3st side placed 4st one, owerwriting 3st one):
So, this time all sides draws on correct place, connects one to each other together, and not broken like GL_QUADS (visually of course triangles, but the point is about right place and connection between).
@Daniel PtitSeb for sure will say that if he can't reproduce and its only on amigaos4, then its we need to find what wrong :(
And, its not that GL_QUADS not used anywhere else, they used all the time everywhere in all other games too, and that they fail there, can mean it fail not because of GL_QUADS itself, but maybe because of the setups before, or some commands which called before which didn't clear what should clear.
In gl4es's drawing.c i find that kind of code:
if (mode == GL_QUADS) {
mode = GL_TRIANGLES;
int ilen = (count*3)/2;
if (iindices) {
gl4es_scratch(ilen*sizeof(GLuint));
GLuint *tmp = (GLuint*)glstate->scratch;
for (int i=0, j=0; i+3<count; i+=4, j+=6) {
tmp[j+0] = iindices[i+0];
tmp[j+1] = iindices[i+1];
tmp[j+2] = iindices[i+2];
@Daniel And with GL_TRIANGLE_FAN same issue as with GL_QUADS. So, it then no conversion of triangles to quads then ?
And ptitseb says that after i check it with GL_TRIANGLE_FAN:
Well, the point is: simple QUADS are transformed in GL_TRIANGLE_FAN in gl4es. But if you force GL_TRIANGLE_FAN, no transform needed, and no transform done. Also, if you put LIBGL_BEGINEND=0, no merging of stuff, and it's send mostly "as-is" to gles2 driver. But here, because each face have a different texture, no merging occurs anyway... So the triangle fan is send untouched to gles2 driver...
Tadam, we come back on the same circle again :))
Also, if keep only 1,2 and 4 , but comment out others, then its even more funny:
I.e. side which should be at bottom, draws on the place of the righg side, but at bottom still nothing (retested over minigl just in case : all draws as should)
If i correctly rewrite those GL_QUADS/GL_TRIANGLE_FAN on proper GL_TRIANGLE , just one first side, then, 2st,3st and 4st sides being in QUAD/GL_TRIANGLE_FAN mode draws correctly, but 5st one start to draws in wrong place.
If i rewrite to proper GL_TRIANGLE 2st side together with 1st one, then, 3st, 4st and 5st sides in QUADS/GL_TRIANGLE_FAN mode start to draws correctly.
And if i rewrite to proper GL_TRIANGLE 1st, 2st and 3st side, then 4st, 5st and 6st sides in that QUADS/GL_TRIANGLE_FAN mode draws correctly too.
It looks like when it more than 3 QUADS/GL_TRIANGLE_FANS something going wrong. But what for sure , is that its only about QUADS/GL_TRIANGLE_FANS, pure GL_TRIANGLE works fine for sure.
So GL_TRIANGLE_FAN must be the trigger then. GL_QUADs are most likely converted to GL_TRIANGLE_FAN internally, given that GL_QUADs don't exist in GLES2, and have been deprecated/removed from newer versions of OpenGL.
I remember adding code to the old Warp3D W3D_SI driver to convert triangle fans to triangles. That boosts performance by rendering multiple tri-fans in one operation instead of having to send them one by one. Does GL4ES or the GLES2 library have something like that? If so, that code should be checked.
EDIT2: Actually, each quad needs to be drawn separately because they have different textures. So, the problem won't be quad->triangle conversion code.
Hans
Edited by Hans on 2019/3/27 5:18:11 Edited by Hans on 2019/3/27 6:05:30
@Hans Yep, Quads in gl4es is triangle_fans, and as i say before using pure triangle_fans instead of quads produce the same errors, while pure gl_triangles is not produce errors of that kind.
In previous post i also put answer from ptitseb:
Well, the point is: simple QUADS are transformed in GL_TRIANGLE_FAN in gl4es. But if you force GL_TRIANGLE_FAN, no transform needed, and no transform done. Also, if you put LIBGL_BEGINEND=0, no merging of stuff, and it's send mostly "as-is" to gles2 driver. But here, because each face have a different texture, no merging occurs anyway... So the triangle fan is send untouched to gles2 driver...
@Daneil Is ogles2 translate GL_TRIANGLE_FAN and GL_TRIANGLE_STRIPs to the GL_TRIANGLE internally before sending them to warp3dnova ?
Is ogles2 translate GL_TRIANGLE_FAN and GL_TRIANGLE_STRIPs to the GL_TRIANGLE internally before sending them to warp3dnova ?
ogles2 doesn't know about quads in whatever style. ogles2 does not mess with the primitive type. It forwards the requested type to W3D Nova. I wouldn't know why a different type would result in different behaviour other than the desired one, for ogles2 it's just a different constant it tells Nova.
@Georg "count" is about vertices, not primitives. So for 1 quad count=4 -> ilen=6.
@kas1e Did you eventually try it with a different optimizer level, -O1 or -O0? Does that make a difference? I know, it may sound naive, but I have my reasons