Lugaru HD

[kas1e]

Hi ! Ported Lugaru HD over gl4es to amigaos4: https://osslugaru.gitlab.io/ https://github.com/osslugaru/lugaru/

It have on my side few issues, dunno if they as usuall amigaos4 drivers related, or gl4es related. The game is "glBegin/glEnd" route (at least i can find them). Version which i try is their last release from 2017:

https://github.com/osslugaru/lugaru/archive/1.2.zip

Take a look at that video: https://youtu.be/4j0f60e-OJ4

Starting from 30 seconds, you can see how textures of the sky and forest start to mirror many times ourself, and you can see bounds of textures of sky. Also issue is very visibly on the level 2, starting from 1:25 seconds on video.

I also tried some older version of the sources (original ones released in 2010) : same issue.

I also build it all for MiniGL : there is no such issues.

Also there is few other differences between issue:

1). fps drop. On minigl with the same settings i have let's say 70 fps, over gl4es i have only 30-40 2). sometime, i can see the same issue which i see sometime in foobillard++ : some walls textures start to be black for a while. So its something related not only to one game then, but to our drivers or to gl4es. On minigl all fine in that terms. 3). when fighting happens, as usuall microfreezes, probabaly because of no precompiled-shaders implemented :)

But main issue at moment is those distored textures of sky and forest.. "setenv LIBGL_GLBEGINEND 0" make no differences on them.

[ptitSeb]

The Skybox is wrong, with texture not drawn as expected. I'll check on the Pandora later to how it runs.

[kas1e]

And not only skybox probabaly, but also forest's textures too. That one very easy to build btw

[ptitSeb]

I don't have the issue you have. As I told you, the skybox is wrong. The faces are not the right ones, and some are not shown at all. Look at a picture just taken on the Pandora:

My guess is that the math used to calculated the coordinates of the skybox vertices get wrong at some points, like with negative values getting discarded or wrapping to positive?

[kas1e]

Did you tried few levels and play a bit in and not only tutorial one ? All fine everywhere ?

Btw, when you fight with enemies you also have micro-pauses ?

[ptitSeb]

No I haven't played, just launched the tutorial. I suspect the micro-pauses are inded the shader beeing compiled. I'll try to test later, but I think the skybox issue is more important. Also, the code for the skybox is pretty small, and all in Source/Environment/Skybox.cpp so it's a good candidate for a fix.

[kas1e]

It just can be that as it was tutorial only, maybe on your side issue didnt arise (low resolution, etc). You may try to choice challange/first level, and move/jump around to be sure there is no issue..

I firstly think it can be game's code , but on minigl all fine, so it can be gles2/w3d then if all fine on your side

[kas1e]

Btw, is your latest commit "Fixed an issue when deleting shared GLXContext" anyhow related to Lugaru ? I have some crash on exit in Lugaru, in glDeleteTexture

[ptitSeb]

Nope, not related to Lugaru. Well, related to SDL2 Context creation, but mainly on X11 platform, not it's relevant on AmigaOS4. You have crash after or before that commit?

[kas1e]

No no, crash happens with previous commits as well. Firstly i need to deal with that strange sky bug, probabaly i can start from just commenting out some parts of code in the SkyBox.cpp to see how it all reacts.

[ptitSeb]

Yeah, try to comment some of the faces, to if can see a difference.

[kas1e]

Tried to comment out everything inside of skybox, it didn't drawns then (some solid red color instead), and , i have that "copy of world" effect in all the parts where sky should be.

I also tried to comment out only parts with "-size" , and it's the same.. Will try to ask Hans and Daniel about, maybe they will have any idea

[kas1e]

Got answer from Daniel, he see that some of the skybox' faces are simply not drawn and what we see are remains of the previous frames because the color-buffer isn't cleared every frame. We can see that the full faces aren't drawn, it's apparently not a wrong z-buffer setup or whatever (we can clearly spot the edges of the missing faces).

We tried to put a glFlush(); after line 157 in that skybox.cpp to rule in/out some theoretical ogles2 issue , but it doesn't change anything so waiting for Hans to answer about.

[ptitSeb]

Yes, of course, the repeated image is a face of the skybox not drawn. But there is more: some of the faces are not the correct one. Look at the clouds, there are not correct and are cut in the edge of your skybox. That why I said that maby negative values are wrapped to positive, and some face are drawn in the wrong coordinate (in place of another face) leading to "broken" clouds.

[kas1e]

And have another answer from Daniel (still waiting Hans's one):

Yes, later in the video there's more. It's either something else, e.g. wrong UVs, or wrong positional coords (which would explain symptom 1 too). As to maybe negative values are wrapped to positive well, how should that happen? And where? I mean ogles2 doesn't do any calculations (exception: current ubyte -> float patcher, which doesn't apply here). Nova only does inside the shaders. Negation of those floats is really nothing that would just magically happen during ogles2 copy procedures (or something).

Maybe gl4es' quad -> triangle conversion is somehow broken ? Sure it works on Pandora, but can be issue show ups just on amigaos by some reassons.

But we need to wait Hans before, it very well can be shaders issue calcualtion.

[ptitSeb]

If it's AmigaOS only, I cannot find it. You need to, I have no machine to reproduce the issue.

Also, using LIBGL_BEGINEND=0 didn't change the rendering, so doubtfull.

Maybe it's related somehow to the issue you have with Foobillard++ that I don't reproduce. Did you got some trace of the vertex attributes?

[kas1e]

By the way, Huno port to amigaos4 Retrun to Castle Wolfenstain Reborn (over gl4es), and i found there is bug, which looks quite kind of same as Lugaru's one. Probabaly it in end will be just warp3dnova issue , but maybe you will have any ideas of what it can be as well..

There is video :https://www.youtube.com/watch?v=LLSHeoaSF50

check from 0:50

Sure its not exactly like Lugaru's issue in some parts, but on others you clearly see how the wrong texture is applied, or maybe the correct texture but falsely applied, or maybe one of the other quads is falsely positioned. Looks really not that far away from the Lugaru symptoms and maybe the same issue or the same combination of issues..

[ptitSeb]

Mmm, difficult to say if it can be the same issue. The effect is different, as the surface is always drawn, but sometime without a texture applied (or the wrong one). I don't think the quad is falsely applied here, because all faces seems to be rendered all the time. Seems it's only happening on the "sky cube map", so "distant" polygons. Anyway, Lugaru is probably easier to debug, because the rendering is overall much simpler than Q3 engine...

[kas1e]

Interesting can it be falsely working shaders cause such issues ? I mean, is it possible at all that let's say some vertex or fragment shader works wrong on warp3dnova , and that cause such effect ?

[ptitSeb]

With that "blinking" effect? No. It's some precision (loss) somewhere (because depending on the angle, the far edget of th epoligon is "too far"), or the order of the draw command that makes a difference, I don't think it can be the shader code.

[kas1e]

By the way, i starting to strip lugaru down to the minimum, so i remove all the terrains, lighting, skeleton, person, objects, models, even sound, everything to make it smaller. In end i just have now when i run game : choice "start game", choise "tutorial", and then, just a pure sky rendering, and via mouse you can move camera , nothing else. Code compiles of course and for minigl (no bug) and for gl4es (bug there).

There is video:

https://youtu.be/5Obdrbi0KUY

First part till 0:30 are minigl binary

Second part from 0:30 are gl4es binary

So it mostly now GLDrawScene() (have lot of glcalls too) + a bit of game logic without gl calls + skybox's glcall.

Now, i think is it possible somehow with gl4es to log the GL calls used to render just that what i have now ?

[ptitSeb]

So, it seems 2 sides are missing. So clearly not a "negative coordinates" effect, because the missing sides are in front of each other.

You can activate logs, sure. Activate DEBUG code in src/fpe.c at least, I think that will be the most interesting. But as it's glBegin()/glEnd() code (if I rememebr correctly), I think you will still not see much interresting things with regular debug code. But maybe start with debug code of fpe, and then maybe you can after that do some specific printfs of some of the VA content, to validate the values send to GLES2 driver.

[kas1e]

Probably even 3 sides, bottom one seems missed too

[ptitSeb]

Mmm, yeah, difficult to understand which side is drawn and wich isnt't. Maybe do a glClear(GL_COLOR_BUFFER_BIT) before the drawing of the skybox to have a more clear view of what is going on. Also, you should comments the side of the skycube and only draw one at time, to see if each individualy are drawing correctly or not.

[kas1e]

Just added glClear(GL_COLOR_BUFFER_BIT) , that how it looks like: https://youtu.be/8yKKeOeHMzE

[kas1e]

Doing more tests now, and:

1). If i keep first 3 sides , and comment out 3 other sides , then first 3 sides draws correctly and where should

video of correct first 3 sides when 4,5,6st sides commented out:

https://youtu.be/-WzgbMkRQzc

2). If i uncomment any of the upcoming sides (4 or 5 or 6) it always places on the place of the previous side. I.e. right on the wrong place of the previous side.

video when firs 4 sides uncommented, can be see how on one of sides placed 4st one, owerwriting 3st one:

https://youtu.be/YxiLJ3Mp9M0

3). Probabaly, its about GL_QUADS in end will be. I just replaced them all on pure GL_TRIANGLES, and

video of what i have with GL_TRIANGLES:

https://youtu.be/8qAJEevFMzI

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

I use for tests more older version of lugaru sources (they a little bit smaller, etc), so just in case there is current skybox.cpp:

http://kas1e.mikendezign.com/aos4/gl4es/games/lugaru/Skybox.cpp

And the file where skybox.draw(); is called (in DrawGLScene(void) , line 345):

http://kas1e.mikendezign.com/aos4/gl4es/games/lugaru/GameDraw.cpp

Dunno what it can be .. It cleary something with GL_QUADS, right ? But then, it works for you .. Maybe implementation of them in ogles2 fail somehow (as probabaly warp3dnova didn't know about GL_QUADS at all as it too lowlevel)

[kas1e]

Daniel says that not warp3d, not ogles2 know about GL_QUADS, so he think that maybe gl4es' quad -> triangle conversion is somehow broken. Maybe something big-endian related in that conversion routine can be ?

[ptitSeb]

Thos videos are interesting yes. Yes, of course, it's gl4es... Err, no, I don't think it's gl4es, as I see no reason why Bigendian would have an impact on quads->triangles. But let's not blame any piece of software for now and just find the source of the issue.

Do you have the same effect with LIBGL_BEGINEND=0 ?

Now, you cannot put glBegin(GL_TRIANGLES); instead of glBegin(GL_QUADS); without touching anything else, that will simply not work, and you push 4 vertices for a triangle that needs 3 or 2 triangles that needs 6...

So from

    glBindTexture(GL_TEXTURE_2D, front); 
    glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
    glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );
    glBegin(GL_QUADS);
    glNormal3f( 0.0f, 0.0f, -1);
    glTexCoord2f(0, 0); glVertex3f(-size, -size,  size); //A
    glTexCoord2f(1, 0); glVertex3f( size, -size,  size); //B
    glTexCoord2f(1, 1); glVertex3f( size,  size,  size);  //C
    glTexCoord2f(0, 1); glVertex3f(-size,  size,  size); //D
    glEnd();

If a QUADS is ABCD, building the same quad with triangles is ABC + ACD so:

    glBindTexture(GL_TEXTURE_2D, front); 
    glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
    glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );
    glBegin(GL_TRIANGLES);
    glNormal3f( 0.0f, 0.0f, -1);
    glTexCoord2f(0, 0); glVertex3f(-size, -size,  size); //A
    glTexCoord2f(1, 0); glVertex3f( size, -size,  size); //B
    glTexCoord2f(1, 1); glVertex3f( size,  size,  size); //C
    glTexCoord2f(0, 0); glVertex3f(-size, -size,  size); //A
    glTexCoord2f(1, 1); glVertex3f( size,  size,  size); //C
    glTexCoord2f(0, 1); glVertex3f(-size,  size,  size); //D
    glEnd();

Should work better (of course, you need to do the other faces too).

[ptitSeb]

Also, another simple test to do, is to simply swap GL_QUADS with GL_TRIANGLE_FAN because there is only 1 quad, both are the same, and GL_TRIANGLE_FAN is understood by gles2.

[kas1e]

Do you have the same effect with LIBGL_BEGINEND=0 ?

No differences, the same

Also, another simple test to do, is to simply swap GL_QUADS with GL_TRIANGLE_FAN because there is only 1 quad, both are the same, and GL_TRIANGLE_FAN is understood by gles2.

With GL_TRIANGLE_FAN same issue 1:1 as with GL_QUADS

[ptitSeb]

Yeah, 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...

[kas1e]

What is intersting , that when i uncomment 4st side , it draws on the place of 3st one. I.e. its like it take the wrong coordinates by some reassons. And not that its something "Random" it always reproducable all the time, pretty stable..

[kas1e]

Dunno what to prinfs there .. I mean even if we will printf values of quads, they just will show us that values is wrong, and not those ones which should be, but then from where and when they come it will not answer :(

[ptitSeb]

And if draw only 3 faces but 1,2 and 4 ? Are they correct?

[kas1e]

If keep only 1,2 and 4 , but comment out others, then its even more funny:

https://youtu.be/9_CRj95BBkk

I.e. side which should be at bottom, draws on the place of the righg side, and at bottom still nothing.

[ptitSeb]

Also, if you want to printf, start by enable DEBUG in src/gl/fpe.c. You wont have vertex attrib value, but that's a start.

[ptitSeb]

Ah yes, interresting effect! And just to be 100%, did you tried to convert the GL_TRIANGLE_FAN to GL_TRIANGLES with the method I gave you earlier (ABCD->ABCACD)? It would be interresting if it work, as that would mean it's on GL_TRIANGLE_FAN only (well, maybe GL_TRIANGLE_STRIP also)

[kas1e]

There is output with debug enabled in fpe.c (watchout , 13mb): http://kas1e.mikendezign.com/aos4/gl4es/games/lugaru/fpe_debug_lugaru.txt

First output come from the level selection, and actually probabaly what we need starts from line 23103, i.e. when latest shader conversion was done.

Will try to convert to GL_TRIANGLES now

[kas1e]

Well, intersting, if i only rewrite to TRIANGLES with your method the "front" one, then 4 sides starts to works correctly : 1st one as triangles, and 2,3,4 one as quads : all looks correct. But if i then uncomemnt 5st, then its overwrite one of sides incorrectly again, and draws not where should. Probably if i will rewrite 2st one to the Triangels, then 5st one will works too then.

[kas1e]

Yeah, as expected, rewriting 2st side on the TRIANGLES, make 3st,4st and 5st quads draws where need it, and all correct. So, rewriting 3st one on triangles, make 4st, 5st and 6st in QUAD mode draws correctly too.

[kas1e]

Its like when its more than 3 quads/gl_triangle_fan something going wrong

[ptitSeb]

Mmm, not sure, because from previous test 1, 2 and 4 draw incorrectly, and it's only 3 QUADS. I think it's more about common vertices here.

[kas1e]

And yeah, GL_TRIANGLE_STRIP is affected too

[ptitSeb]

Another thing you can try is one case that doesn't work (like the 1,2,4 case), comment the glTexCoord2f(...) of only 1 face, and see if it does the same. Only one face to make sure gl4es wont merge face (as that would remove the triangle fans then). Just to see if the texture have an effect or not. Also, you should try to make a sample with the 1,2,4 drawing. Take one of you old SDL2 sample, create 3 dummy texture (like with just 1 pixel red, green and blue) and use the skybox drawing code. Hopefully it will reproduce the cod and will much simpler to debug (because it wont have all the menu stuff mainly).

[kas1e]

Another thing you can try is one case that doesn't work (like the 1,2,4 case), comment the glTexCoord2f(...) of only 1 face, and see if it does the same. Only one face to make sure gl4es wont merge face (as that would remove the triangle fans then). Just to see if the texture have an effect or not.

Yeah i tried to to have 1,2,4 case, and then in the face 1 comment out 4 glTexCoord2f(), and result : 4st face draw correctly and where need it !

Then i uncomment one glTexCoord2f() (first one) on the first face, having still commented out 2,3,4 glTexCoord2f of that 1st face : still 2st and 4st faces draws correctly. Then i uncomment also 2st and 3st glTexCoord2f of the 1st face (so only 4st glTexCoord2f of 1st face is commented out), and : it all still draws correctly , just the 1st face of course have only triangle and not quad drawed, but still 2st and 4st faces drawed correctly and on the places where they should be.

And only when i uncomment 4st glTexCoord2f back, it start to mess things again.

Now, i replace 4st glTexCoord2f of first face which is :

glTexCoord2f(0, 1); glVertex3f(-size, size, size);

on

glTexCoord2f(0, 1); glVertex3f(size, size, size);

So, all start to works fine again (but quad of course, didn't draws properly).

Then, if i put back "-" before any of 3st size, then not only it draws not as quad (its expected of course), but it broken again the whole things.

[ptitSeb]

Ok. So issue is with textured "quads"... and what about glTexCoord2f(0, 1); glVertex3f(-size/2.0, size, size); ?

[kas1e]

You mean instead of 4st glTextCoord2f of 1st face ?

[kas1e]

With that one all fine !

[ptitSeb]

That's very strange. That looks like there is some "optimization" that take common stuff (vertices/texels) and mutualized them, somehow. But that also can be something completely different. Not sure at all were this can comes from, but I highly doubt the issue is inside gl4es.

You should focus on getting the minimum program I mentioned earlier to work. Also, the advantage of the minimum program is that you can also compile it without gl4es with some little adaptations (from 3glBegin/glEnd to 3glDrawArrays, but nothing to difficult).

[kas1e]

I probabaly can take just one of the those examples i do at begining with minigl/gl4es (i.e. even without SDL), and just instead of the loading of textures make dummy ones as you say.

[ptitSeb]

Yep.

Also, for the sake of compleness, if you change all the -size with -size/2.0, the drawing is back to incorrect, right?