@Capehill For sake of tests, try to replace in your test case, quads (or if it triangles_fans), on pure GL_Triangle : will then all works fine ? (taking aside wrong visuall rendering).
If it will be the same works fine with GL_Triangle, but works wrong when it quad/triangle_fan, then its 99% the same issue as i have in lugaru then
Btw, your quad_mystery test case are with pure glColors , no textures ?
But at least it the same renders fine in first frames, and then make things messy after few frames. The same as in lugaru's case too. It should be something common between for sure ..
Tried just with glColor's instead of textures : no issue. So issue happens when we have textures exactly : being it real textures, or dummy ones of filled colors does not matter.
I hope in end it will be not something about Sampler2D in the shaders ..
Inside there is directory "bin" , in which just 2 binaries gl4es one and minigl one. Which use just 2 files from Data directory : config.txt and map/tutorial.
So to check how binaries reacts on your systems. ("esc" for quit).
Also there directory source, in which current stripped test-case , which is easy to build doing or "make -f Maekefile_mgl" or "make -f Makefile_gl4es" (necessary libSDL_gl4es, libGLU_gl4es and libgl4es placed in the root of source , from where gl4es makefile will take them, so nothing to worry).
Currently what we do there , is use for building those faces "GL_TRIANGLE_FAN" and dummy textures, content of which are colors (that all can be seen in skybox.cpp).
Give it a go, at least to see if on your systems its all the same as on my (i.e. minigl binary works fine, but gl4es one made wrong faces and co).
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 :)
The only way would be to let the debug log go to memory, and use dumpdebugbuffer to capture. Of course, you're only going to see the last part of the log.
Maybe you could do that, and then execute kdebug "console serial" for just the bit you actually want to capture.
Another option would be to try increasing the serial port's speed and hope that the other computer can handle it.
Quote:
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:
No. Look closely at your slowed down video. After a number of seconds, the the left-most side goes a very dark grey, whereas the bottom one goes black.
Looking at your source-code, none of the sides are a dark grey, so where is that coming from? Is that your clear colour? Your video doesn't show all the sides, so I commented based on what I see.
Quote:
In post 513 i post the code, where i create 6 different textures of different colors.
Sigh. Why on earth did you do it that way? So yes, that's why I see a texture being created every single draw call. I didn't see post #513, so of course I thought I'd spotted something wrong.
The next few frames also have one VBOLock and BufferUnlock call despite having 6 quads to draw, and only three VBOs to store the vertices in (DrawArrays is always DrawArrays(W3DN_PRIM_TRIFAN, 0, 4), so each VBO stores only one quad's vertices at a time). So, some quads have started to be drawn with the wrong vertex data.
Looking at your source-code, none of the sides are a dark grey, so where is that coming from? Is that your clear colour? Your video doesn't show all the sides, so I commented based on what I see.
Yeas, its a clear-color. On that slow video i don't show all the sides because it very slow to even move mouse when capture log, i was hope, that you watch previous video, where clear color the same, and i show all sides :)
Quote:
Sigh. Why on earth did you do it that way? So yes, that's why I see a texture being created every single draw call. I didn't see post #513, so of course I thought I'd spotted something wrong.
I will put creating of dummy textures to the load() function, so there will be no lots of the same things, and probably it will make log more readable then.
I've downloaded your minimal example, and added a few printf()s to the driver for just the calls I'm interested in. Here's what I see:
That mean also you was able to build gl4es version with no problems ? Good !
Quote:
I can now conclusively say that the bug is upstream from Warp3D Nova.
Dunno if i right translate that phrase, but you mean its can be Nova in end ? If so, can i help more with this ? I can reduce it pretty much more for sure
That mean also you was able to build gl4es version with no problems ? Good !
No. I added the printf()s to the driver.
Quote:
Dunno if i right translate that phrase, but you mean its can be Nova in end ? If so, can i help more with this ? I can reduce it pretty much more for sure
No. It's upstream from Warp3D Nova. The bug is NOT in Warp3D Nova.
@Hans Btw, just in case, can you check via the same printfs you put to the driver, the Capehill's testcase , where he draw 4 quads, and then, after few frames , 3 of them just disappear (just to see, if it the same issues or not).
@Hans Also checking warp3dnova log more, we see there ctxCreateVertexBufferObject, but gl4es don't create any VBO (i.e. it's using default VBO 0).
Taking in account our gl4es trace above there drawing command were the same all the time.
So, if VBOs seems to created by ogles2 driver, we need some trace from ogles2 to go forward. Because what we see from warp3dnova log and gl4es logs, things looks different.
So hope Daniel will be able to build version which print all those va, dbo, and whatever else can help us to see what and where going wrong
Btw, just in case, can you check via the same printfs you put to the driver, the Capehill's testcase , where he draw 4 quads, and then, after few frames , 3 of them just disappear (just to see, if it the same issues or not).
Something similar is happening. After the first few frames, the VBOLock calls disappear.
Oh my god, one trillion new posts... Luckily I don't have to read them You can stop it now, I found and fixed the issue on my side when handling another remaining problem reported by Capehill a week ago. This turned out to be the cause for this here too. The problem was in a quick-step data hasher which caused the hasher to produce identical hashs for very small only slightly different data packets.
You can stop it now, I found and fixed the issue on my side when handling another remaining problem reported by Capehill a week ago.
Omg, that cool !
That remaining problem reported by Capehill was that "quad_mystery" thing ? (its just in last pages we find connection and the same symptoms between lugaru bug and quad_mystery)
@Hans
Quote:
Phew! Glad this one's finally done. Hopefully we won't have any more really strange ones like this.
Easy bugs probabaly fixed long ago, the remaining ones will be harder and harder imho :)
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
Luckily I don't have to read them 
