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.
And to check if the issue is the -size value or the fact it's a common value among the faces, i replace everywhere in all faces "-size" thing on "-size/2.0". And whole cube renders correctly ! All faces where they should be.
And all tests done now just with GL_TRIANGLE_FAN, to avoid all of us even worry about "QUAD" type and its conversion.
A bit more hacking skybox.cpp, and just made 2 values for sizes:
static float size= 25; static float size2= -25;
And put it in use (so in all faces size where was size, and size2 where was -size).
Now, once values the same 25 and -25, or 15 and -15 or any other value just one with "+" and another with "-" : then bug is here.
Once ANY of values changes a bit, like 25 and -24, or 25 and -26, or 24 and -25 , then everything works fine !
So issue is exactly when values are the same. It's like, some optimisation when done, 1 maybe changes to -1 as start value, or to 0, or something of that sort.
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 ?
Hehe. Warp3D Nova just passes the whole lot on to the GPU. Shall we blame the hardware?
The tests where you're messing around with the vertex coordinates are giving really weird results. Have you tried recompiling the entire game with optimization disabled? Remember to do a clean full rebuild.
EDIT: You should also compile GL4ES without optimization in this test.
Hehe. Warp3D Nova just passes the whole lot on to the GPU. Shall we blame the hardware?
:) at least the only place where optimisation involved with triangle_fans are nova if taking in account that it transfered untouched in gl4es and ogles2..
Quote:
Have you tried recompiling the entire game with optimization disabled? Remember to do a clean full rebuild.
Yeah, in post 499. In short, recompiling of game with O3, O2, 01 and O0 give exactly the same results.
Will try to recompile gl4es without optimisation too just in case.
And after last tests ptitseb says that: That is really odd! You need to send that to low level Warp3d dev. I guess.
@Hans, Daniel
So everyone point by finger on another one. Is there any way for me , not having sources of ogles, or warp3dnova to fix anything ?:) It all start to feels like crap when none of devs want to deal with.
What about making some debug versions of ogles2 and warp3dnova, which will come with releases, which can printf all the crap, so when one want to find the truth, he can use debug versions, where via ENVs control what to print, etc ?
So , we can find the guilty and with lugaru bug, and with frickingshark (those 0xFFFFFFFF coming from nowhere , but not from gl4es for sure) one ?
Common .. What can i do if everyone point by finger on another one, even when i made sooo deep tests ?
Sorry kas1e. This is a really weird one, and so far none of us can think of a way that our code could trigger this behaviour. I hope you'll continue to be patient just a little bit longer.
I just thought of one possible way this might happen. If the same VBO is reused for multiple quads/tri-fans but the offset/indices used get out of sync with the vertex data, then it might cause what we're seeing.** Remember how the texture in the top quad is rotated wrongly? Well, if the wrong offset/indices were used, then one or more of the vertices would be from the previous quads/tri-fans, which could cause what you see. Assuming things get further out of sync with each quad, then the later quads would get even worse.
This is just a guess, but it's as good as anything else we've thought of so far. You could test the theory by changing the order that the quads are drawn in, and seeing what effect that has.
Hans
P.S., I thought you already had access to the debug version of Warp3D Nova.
** By this I mean that the start index in glDrawArrays, or the indices passed to glDrawElements are out of line with where the vertex data is actually stored.
@Hans That theory can be ok for Fricking Shark issue probabaly, but that doesn't explain Lugaru's one: why when we have +25 and -25 don't work, but changing any value to be not equal to another one made it works.
Quote:
I thought you already had access to the debug version of Warp3D Nova.
I have only access to the betas (1.63 currently), but what i mean, is debug versions of warp3dnova and ogles2.library for debugging purposes.
I.e. not the versions with debug symbols which can help when crash happens, but just special , "developers" versions, which will have ability to be controlled via ENVs and while anything works over that library , print necessary low-level things (to console, or to serial, or to file, that also can be choicen via ENV or somethign).
For example, if one want to printf VA when game in running which handle warp3dnova at moment, then:
setenv W3DNOVA_DEBUG_VA 1
and when one run app, then that special debug warp3dnova library will print to console (or to file, whatever, or to serial), what need it.
same for example if we need to printf something from ogles2.library, if there can be the same debug version of library, then it can be something like
setenv OGLES2_DEBUG_DBO 1
and it will print all DBOs when app which use ogles2.library is used.
By that way, every user/developer can debug later everything more deeply, and provide to you or to daniel ready to understand information.
I mean, its not usuall libraries with debug symbosl attached to, but special versions which will help to debug things in realtime.
That theory can be ok for Fricking Shark issue probabaly, but that doesn't explain Lugaru's one: why when we have +25 and -25 don't work, but changing any value to be not equal to another one made it works.
Could you please just try what I asked?
For the record, when I say that the driver just passes it on to the hardware, I mean it. The driver literally tells the GPU to draw a tri-fan using the specified vertex data, texture and shader pipeline. Likewise, when the vertex data is transferred to the GPU, all that the driver does is convert the endianness and copy it over. At no point does it peek at the data and do stupid things like check if the coordinates are +/- the same value. The shader can't be responsible either, because it only operates on one vertex at a time, and can NOT check what the previous vertex was and do silly optimizations.
Quote:
I have only access to the betas (1.63 currently), but what i mean, is debug versions of warp3dnova and ogles2.library for debugging purposes.
I know what you mean, and I expected you (and all beta testers) to have access to the version that spits out debug info. I'll make sure you get access to it...
EDIT: BTW, if you have a *.debug version of the driver, then that *is* the one that prints debugging info.
I've taken a peek at GL4ES' code, and it has code to convert both GL_TRIANGLE_FAN and GL_QUADS to GL_TRIANGLES. I don't know if that code is being used, because there are config variables to enable/disable various features. Differing config settings may also result in code working on one system but not another...
I hope Daniel's got a gl-call logger for you to use. Otherwise the debug version of Warp3D Nova should make it clearer whether GL_TRIANGLE_FAN is or isn't being converted.
This reminds me that it would be really useful to have debugging tools like apitrace for OpenGL and Warp3D Nova.
@all If anyone's looking for a porting project, please have a look at apitrace.
If the same VBO is reused for multiple quads/tri-fans but the offset/indices used get out of sync with the vertex data, then it might cause what we're seeing.
This could be something indeed. It is not likely that the primitive type is the culprit, even if some (I didn't read everything, too much **) of kas1e's tests seem to point into that direction. If it was we'd see broken stuff much more often than we do. And a bug at that area is extremely unlikely in ogles2 and Nova because both don't do anything depending on the primitive type. A bug in the gl4es' primitive conversion / merging appeared not impossible (wasn't there one in the merger before?), but also rather unlikely, I suppose it would have been found by now. And the latest tests seem ** to rule that out. A wrong starting index however (or maybe more likely, data copied to the wrong offset) would explain all symptoms. Well, almost: changing the numerical value of the edge size shouldn't make a difference, but maybe I overread or misunderstood something here.
@kas1e Quote:
So everyone point by finger on another one. Is there any way for me , not having sources of ogles, or warp3dnova to fix anything ?:) It all start to feels like crap when none of devs want to deal with.
Calm down. No, you can't fix anything. You only can throw stuff to us as you do and wait and hope for the best. It is nonsense to say that "none of devs want to deal with". We fixed / improved / extended so much in the past, so please.
However, believe it or not, I at least also have other things to do. I spent hours on this forum alone the last two weeks on multiple 3D lib coding topics. But even if it was my fulltime-job (and it is not): this stuff takes time, especially if it's weird stuff like this one here.
If you look back you will eventually notice that we all made mistakes in the past and that every aspect, be it gl4es, ogles2, nova or even the game in question already turned out to be the cause of trouble at the end. So please spare us such "everybody points to the other" crap. We are all thinking loud here, brainstorming, and if sb. of us thinks that this or that is likely (not) the cause, then he doesn't say so because he cannot admit a mistake on his side.
** IMHO, to improve readability here and to make it easier to follow and to keep track, it would be best if you'd merge your posts. I mean, instead of writing 5 posts 499 to 503, it would probably be better to only write one and edit / extend it, until somebody answers.
Originaly we draw it like 1,2,3,4,5,6 faces, so i tried that:
2,1,3,4,5,6 - nothing changes , last 2 textures overwrite first 2 ones and 6st one change the place as well. 6,2,1,3,4,5 - the same, last 2 textures , overwrite places of first 2 ones and 6st one change the place as well.
In other words, does not matter what : first 3 faces always draws where they should be and of correct look. But then, if we add 4st or 5st faces (or both at the same time) then they overwrite 3st one and 1st one. And when all 6 faces draws, it mess things even more: only top (2st one) one stays correctly , but other ones change and place and color.
If you need more better explaining, you can ask based on the source coming next, which faces and in which order put, and i will made just a videos.
Quote:
I've taken a peek at GL4ES' code, and it has code to convert both GL_TRIANGLE_FAN and GL_QUADS to GL_TRIANGLES. I don't know if that code is being used, because there are config variables to enable/disable various features. Differing config settings may also result in code working on one system but not another...
Ptitseb says that conversion will happens only if needed. Here, in our case, it is not needed, because the merger is not used. So GL_TRIANGLES_FAN will be sent as-is.
@All
At moment i strip lugaru so much, that its now have no menu, nothing, just you run binary, and it show that cube, and "Esc" exit from, few days more and it will be simple test case probabaly.
I even remove totally textures, and use just dummy colored textures (white,black, red, green, blue and yeallow), so i can see easyly now what-where.
from begining till 0:13 minigl binary , and from 0:14 till end the same code compiled via gl4es.
If watch closer when gl4es vesion runs (between 14 and 16 seconds) can be seen that first 3 faces draws firstly, and then immediately overwrites by next 3 ones, as well as a change a place a bit (just like i describe above)
Edited by kas1e on 2019/3/28 11:33:05 Edited by kas1e on 2019/3/28 11:48:21 Edited by kas1e on 2019/3/28 11:49:20 Edited by kas1e on 2019/3/28 12:24:06 Edited by kas1e on 2019/3/28 12:27:47
EDIT: BTW, if you have a *.debug version of the driver, then that *is* the one that prints debugging info.
Yeah, checked what you send me, and i for sure first time see any debug versions of nova. Is it can be controlled somehow via ENVS to what print ? Because it print soo much that it slow things down veeeeery.
But, what is interesting , with such a massive slowing down, i can see frame per frame what happens:
1). I run test case. 2).First frame: whole thing draws correctly ! I surely can see 5 sides of correct look and of correct place (just can't move mouse as everything slow down because of serial output, but i for sure can see that it draws all fine on first frame
And probably for about 10 or more frames (i cant count , but more than one, as i can see some "fade in" thing happens and take more that one frame) it all draws correctly.
3). And then bum at some point faces fucked, and 3 of them disappear, and previous one change the colors.
So originally, all faces draws correctly as can be seen. Then they messes later, after few frames. And, the mess itself, happens also not in one single frame, but in few : firstly can be seen that 2 faces disappear, and then on next frame another one.
And there i catch the log from debug version of NOVA, till the moment when those faces start to render wrong (i.e once faces start change and make a wrong look, i just halt output and save it to file):
Yeah, checked what you send me, and i for sure first time see any debug versions of nova. Is it can be controlled somehow via ENVS to what print ? Because it print soo much that it slow things down veeeeery.
Sorry, but no. There's no way to control how much debug output is printed. The debug output was never meant for application debugging, which is why it doesn't print the function parameters, either.
I always intended for Warp3D Nova to have debugging tools like apitrace I mentioned earlier.**
Quote:
And there i catch the log from debug version of NOVA, till the moment when those faces start to render wrong (i.e once faces start change and make a wrong look, i just halt output and save it to file):
I've spotted something strange in the log: Textures are being created continuously in between the draw calls. If the game is drawing just a six sided skybox, then it should load the textures once, and just bind them repeatedly. Your log shows 76 textures being created in between 109 draw calls (i.e., while it's rendering the game world). Plus, none of the created textures are destroyed. Clearly that's not right.
EDIT: And, the last part of the log shows a new texture being created for every draw call, so a 1:1 ratio. That definitely doesn't make any sense.
I also notice in your video that one of the sides changes to almost black instead of transparent. So, the quad is being rendered, but the texture has been replaced. The fragment shader calls "discard" for texels with alpha <= _gl4es_AlphaRef. So, if a texture were replaced with a transparent one, then you could get missing faces just like you showed in the original video.
Looks like we've been searching for the bug in the wrong place. Something's going wrong with the textures. Why are new textures being created continually? It could be legitimate if Lugaru loaded textures in the background, but I'd expect them all to have been loaded before it starts rendering the game world. Next question: how could some of the skybox textures get wiped? And why would changing the vertex coordinates have any impact on that?
Hans
** Yes, I'm repeating myself here because it really would be great if someone could look at apitrace and bring it to AmigaOS. Having a tool like that really would help debugging OpenGL (and Warp3D Nova, if it were added to the list of APIs that it can log).
In the post #513 above kas1e seems to be creating texture for each side.
Regarding API tracing, I would contribute to such a project. I have no idea how portable these open source tools are, but I guess it would be possible to "patch" each OGLES2/Warp3D(Nova) call to capture data. Or how would you approach the issue?
@kas1e
To create colors you could use glColor calls as well, no need for texture unless the issue is related to textures.
Sorry, but no. There's no way to control how much debug output is printed. The debug output was never meant for application debugging, which is why it doesn't print the function parameters, either.
Is there any way to speedup executing of the games, but still take the debug output ?:) Just with current output, it will be unpossible to run some games as it will take hour to reach menus, etc :)
Quote:
I always intended for Warp3D Nova to have debugging tools like apitrace I mentioned earlier.
Apitrace portable, just it should be done right, not like some fast port, but someone skileld enough should step in. That will also require to write some gui backend (reaction or mui) where one can operate with logs, etc. Like on example screenshot which ptitSeb shows some-ten-pages ago.
Quote:
I've spotted something strange in the log: Textures are being created continuously in between the draw calls. If the game is drawing just a six sided skybox, then it should load the textures once, and just bind them repeatedly. Your log shows 76 textures being created in between 109 draw calls (i.e., while it's rendering the game world). Plus, none of the created textures are destroyed. Clearly that's not right.
I will not count at moment on the whole log. As it still lugaru, with something not stripped down. Its just i strip at moment as much as i can, but i still can do something not related to the showing our issue. I just was in hope, that "end" of log will help somehow to show why at some point faces changes.
Quote:
I also notice in your video that one of the sides changes to almost black instead of transparent. So, the quad is being rendered, but the texture has been replaced. The fragment shader calls "discard" for texels with alpha <= _gl4es_AlphaRef. So, if a texture were replaced with a transparent one, then you could get missing faces just like you showed in the original video.
You probabaly mess it with glClear(GL_COLOR_BUFFER_BIT); which i call before skybox.draw(); to clear the background when move camera. As far as i can see it happens like this:
1). everything renders corectly in some first frames 2). after a while (10 or more frames), few faces draws not where they should 3). and in next frame, another face draws not where should, and one of previous one pure disappear (and then gl_clear make it looks not black).
I.e. there no transaprency or anything happens as far as i can see.
In post 513 i post the code, where i create 6 different textures of different colors.
Quote:
Looks like we've been searching for the bug in the wrong place. Something's going wrong with the textures. Why are new textures being created continually? It could be legitimate if Lugaru loaded textures in the background, but I'd expect them all to have been loaded before it starts rendering the game world. Next question: how could some of the skybox textures get wiped? And why would changing the vertex coordinates have any impact on that?
What you mean by wiped ? Issue still the same, just i change texture on begin color ones : 6 different colors for 6 different textures (faces).
But yeah, probabaly we search it in wrong place. At first it draws for sure as should, then, after few frames mess starts. What it mean, is that more GL commands involved in the frame-rendering, which can have impact on.
Its not like its at moment just simple test case which draw cube + camera, there is still left outs of Lugaru in the rendering of frame, which stil full of gl-calls of different kind, which i trying to reduce with keeping bug.
But probabaly what is more important for us is that first few frames 100% draws correctly with the same skybox code. Its after a while, after some redrawing things going bad.
@Capehill
Quote:
In the post #513 above kas1e seems to be creating texture for each side.
Yeah of course, i specially show the code : i create 6 dummy textures of different color.
Quote:
To create colors you could use glColor calls as well, no need for texture unless the issue is related to textures.
Well, that idea .. We can try to get rid of textures at all, but use colors on the same place of the same size, to see, if it anyhow related to textures.
Edited by kas1e on 2019/3/28 17:45:33 Edited by kas1e on 2019/3/28 17:49:10
Regarding API tracing: GUI can come later. First things first :)
Regarding Lugaru: remember quad_mystery.lha test? I added a frame counter and 1-sec delay in render function, and it seems to me that in this case, the first 5 frames are drawn correctly, then 3/4 of quads "disappear".
Regarding API tracing: GUI can come later. First things first :)
It is quite portable for sure, i few times starting to looking at this, but just realize it need some normal developer if we want to make it all right and not half of working.
Quote:
Regarding Lugaru: remember quad_mystery.lha test? I added a frame counter and 1-sec delay in render function, and it seems to me that in this case, the first 5 frames are drawn correctly, then 3/4 of quads "disappear".
Whoa whoa ! Is it the same issue then ?
There is exactly what happens: first frames renders as should, and then issue come after some frames.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
