@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
The code segment you quoted might not be used in this case. Have a look for "mode==GL_QUADS" in the same source-file. The GlDrawArrays() has its own quad to triangle conversion code. I'm not familiar with GL4ES' code, so I don't know which function is called when glBegin()/glEnd() is used.
ogles2 doesn't know about quads in whatever style.
Same issue is with GL_TRIANGLE_FAN and GL_TRIANGLE_STRIP as well.. but if you say that "ogles2 does not mess with the primitive type. It forwards the requested type to W3D Nova." , then probably it can be Nova in end ? Expectually if, as pritseb says, GL_TRIANGLE_FAN also sending untouched to ogles2 (which, resend it untouched to the warp3dnova) ?
Quote:
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
Now, the next thing i tried, is to take the known to not work case like 1,2 and 4st face (yes, when there is just even 3 faces, but not one after another , but 1,2 and 4) then, instead of drawing 4st face on the bottom, its overwrite 1st face.
And then, i for sake of tests start to comment one glTexCoord2f() in first face one by one, and result are:
1). when keep only first glTexCoord2f(), but comment out 2,3,4st ones in first face: nothing draws (expected), but 4st face draws where should.
2). when keep 1st, 2st and 3st glTexCoord2f(), but comment out only 4st one, then, i have triangle on first face (of course expected), and 4st face still connects fine ! and all draws fine.
3). then, i take that 4st glTexCoord2f() of first face which is:
and remove "-" thing. And then again, 1st face of course draws not as quad , but then other faces draws correctly !
And then, if i put "-" to any size of 3 arg in that 4st glTexCoord2f, it always broken the whole drawing of the 4st face, and it overdraw the first face.