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