Please spend a bit more time looking for the root cause first. Especially check whether the skybox rendering code is disabling the depth buffer (in which case we need to check whether that's actually happening).
Seems we (mostly gl4es guy of course, i only do tests on my side when follow his suggestions) found roots.
Short story: OGLES2 or W3DNOVA doesn't like to have a depth range that is not a range.
Long story: Rendering of Sky in the Q3 happens in the file code/renderergl1/tr_sky.c. There is relevant part of code:
/*
================
RB_StageIteratorSky
All of the visible sky triangles are in tess
Other things could be stuck in here, like birds in the sky, etc
================
*/
void RB_StageIteratorSky( void ) {
if ( r_fastsky->integer ) {
return;
}
// go through all the polygons and project them onto
// the sky box to see which blocks on each side need
// to be drawn
RB_ClipSkyPolygons( &tess );
// r_showsky will let all the sky blocks be drawn in
// front of everything to allow developers to see how
// much sky is getting sucked in
if ( r_showsky->integer ) {
qglDepthRange( 0.0, 0.0 );
} else {
qglDepthRange( 1.0, 1.0 );
}
// draw the outer skybox
if ( tess.shader->sky.outerbox[0] && tess.shader->sky.outerbox[0] != tr.defaultImage ) {
qglColor3f( tr.identityLight, tr.identityLight, tr.identityLight );
// generate the vertexes for all the clouds, which will be drawn
// by the generic shader routine
R_BuildCloudData( &tess );
RB_StageIteratorGeneric();
// draw the inner skybox
// back to normal depth range
qglDepthRange( 0.0, 1.0 );
// note that sky was drawn so we will draw a sun later
backEnd.skyRenderedThisView = qtrue;
}
As you can see at top of function, there is qglDepthRange( 1.0, 1.0 ); call, which is not "range" as it, but still should work anyway. Once we replace it to be some kind of range, i.e. on qglDepthRange( 0.9, 1.0 );, then everything works as expected.
Then, to be 100% sure that it is issue with "range not range", we change it on 0.9, 0.9, and it again broken.
So, that mean that ogles2 or nova doesn't like when glDepthRange range is not range.
@all There was another round of fixes in warp3dnova, so issues with sky overlaping in quake3 and wrong alpha colors in neverball are gone.
Through that issue which we have when enable extensions and have mess all over the screen still here, and probably i will just try to strip down source of the quake3 till the moment when bug still triggered, but sources left will be small as possible.
But glBegin/glEnd route works fine, and all renders correctly now. And so i compare minigl version and latest gl4es one , and in the same 1600xx1200, with all on maximum, 32 bit , etc i have in timedemo1/demofour for minigl: 44.5 fps, for gl4es version 40.5 fps. So, almost on pair, but not faster surely.
But (!), rendering in the gl4es version is more accurate and better in compare with minigl version. For example, there is places in minigl version where it just all renders wrong. Like first level where we watch over the mirror.
See there in minigl version at first no mirroring, and when we come close to mirror, there ugly black triangles on floor.
(press on open in new tab for fullsize)
(press on open in new tab for fullsize)
And thats gl4es version, where all looks correct:
(press on open in new tab for fullsize)
(press on open in new tab for fullsize)
Or for example some portal: In, minigl version, there again ugly black trianges visibly, and rendering of what we see ghosted in portal not correct in whole:
(press on open in new tab for fullsize)
And gl4es version, where all renders correctly:
(press on open in new tab for fullsize)
Surely that all not big deal today, but just point out on those tasty little details which some of us love :)
Also ptitSeb (gl4es author), works almost every day on improve gl4es, so good for us.
What is left now, is to deal with that strange bug when we have mess on screen when enable extensions in quake3 (and the same bug we have in irrlicht engine), and, if after that one fixed, there still will be memory trashing about which we talk few pages before, then that one as well.
Perhaps for the MiniGL bug you may contact Daytona, recently he still worked on the MiniGL side
Actually the recent bug fixes were only a side-effect of what I was really doing: adding the std.PPC<->SPE-ABI bridge to the libs so that programs compiled for std. PPC could attach to (at least internally) native SPE MiniGL / mglut libs. Such a bridge is always necessary if std.PPC-code shall talk to PPC-SPE-code and float-parameters are involved, because the PPC-FPU- and PPC-SPE-ABIs are incompatible when it comes to floats, naturally, because usually float parameters are passed via FPU-registers, which simply don't exist on PPC-SPE (on such systems such parameters are expected to be in GPRs instead). Anyway, I simply fixed what I saw when doing some cleanup. I don't plan to otherwise invest much time into regular MiniGL, especially because my own MiniGL replacement lib is progressing well (some of the MiniGL fixes also came up because I noticed differences when comparing my lib with the output of std. MGL, which in some cases was due to std.MGL bugs).
That Q3-issue with the broken geometry in the mirrors / portals here smells like clipping-bugs in MGL. However, I noticed that W3D for e.g. old Radeons and W3D for SI behave different when it comes to clipping (and I don't mean R200-guard-band-related effects). It may also be that this here is an incompatibility (compared to other earlier W3D implementations) inside the W3DSI-driver.
EDIT: no, I just checked it on my sam440, it happens there too, so you can safely asume that it's a MiniGL-bug, most likely related to clipping.
I just noticed someone on amiga-ng.org claiming that GL4ES is slower than MiniGL. It might look that way based on what kas1e has said, but let's look deeper.
Quake III on GL4ES may have achieved 40.5 fps in the time demo vs 44.5 in MiniGL. However, his test uses the slow glBegin()/glEnd() render path due to a bug in GL4ES preventing the use of compiled vertex arrays. It'll be interesting to see what the performance is once that bug is squashed and compiled vertex arrays are used.
Which one is faster will probably depend on what's being rendered. I expect GL4ES will have the edge when large meshes with lots of vertices. When it comes to rendering lots of tiny meshes, then the bottleneck is how many render ops/s the system can manage. The W3D_SI Warp3D driver has code to accumulate lots of tiny meshes into batches precisely reduce the effect of that bottleneck. So, it may have an edge rendering smaller meshes. Exactly what size mesh is the threshold where it flips in GL4ES' favour is uncertain at this point (and is likely to change over time).
Hans
EDITED: Corrected based on kas1e's response.
Edited by Hans on 2018/6/9 7:45:32 Edited by Hans on 2018/6/9 7:48:47
@Hans 40.5 vs 44.5 its of course when both versions runs without enabled extensions, so glBegin/glEnd in both cases. With enabled extensions minigl scored about 90 fps if i remember right, but i dont point on it, as gl4es version cant be running with enabled extensions due to that hardcore bug, which still unclear where to look, as seems from ogles2 side all is ok. I only can try to reduce q3 code.
From another side, if we take neverball/neverputs games, they faster a lot in compare with minigl versions. I.e when minigl give 20 fps, gl4es give 40-50 fps
Okay, I've corrected my post above. It's interesting that Neverball/NeverPutt is faster with GL4ES, as I assumed that its models also have a low-polygon count.
BTW, any progress in figuring out why compiled vertex arrays get all messed up?
BTW, any progress in figuring out why compiled vertex arrays get all messed up?
When ptitSeb checking it all before, we come to conclusion that it's the glVertexAttrib with GL_UNSIGNED_BYTE and Normalize TRUE that break things. It's use for the Colors (and it's converted to GL_FLOAT when using glBegin()/glEnd() code path)..
To check that theory we just made a workoround like this:
And it make everything works. And q3 with enabled extensions and irrlicht engine.
Then, i bring that all info to Daniel, but that didn't help us, as from ogles2 side still everything looks correct. And, Daniel explain as well that if it was issue with normalisation, distortions can be of color only, not of geometry.
But that again, can be not only normalisation, but normaisation + something else + whatever else..
In end of all, i just create another bz on the gl4es page (just to summorize everything about that issue):
If you want to check it for real yourself, there is 2 test cases.
1. Quake3
That one you can download from Daniel's ftp from REPORTS_HERE/q3_test.lha , also take q3_batching_fixed.zip from the same place. Then, once you will enable extensions in q3 (and quit/run again), you will see everything yourself (don't forget to hit "enter" few times after first anim movie disappear).
2. Irrlicht engine's hello-world
You can download it from the same Daniel's ftp, from REPROT_HERE/irrlicht_example.lha. There you will find 2 binaries. One called "non_hacked", its original, which show bug. And another one, with that workoround i post above, which render all correct. So you may compare them too. Maybe, irrlicht engine's test will be easer than q3 one.
Don't forget to unpack them as it, and run it from the same "bin/amigaos4" directory, as it will search for data from ../../media/.
That test case probably will be more easy than q3. At least size is smaller.
I can't comment on the internals of GL4ES and ogles2.library. However, the W3DN_SI driver currently can't handle anything other than 32-bit datatypes (it says so in the readme). So that excludes GL_UNSIGNED_BYTE.
The problem is that Southern Islands and newer GPUs are little-endian only while our CPUs are big-endian. So the driver has to convert the endianness as its copied to the GPU. Right now it assumes that everything is 32-bit, and it probably returns an error if you try to use 8/16-bit vertex data.
Writing a system to perform the correct endianness swapping for the data is on the to-do list. It'll be a bitch to get right, because it's got to handle interleaved data, structures with different datatypes, etc. It's one of those things I wish I could get someone else to write...
@Hans In case with gl4es: everything converted to 32 (you may remember i post that info in alpha bug bz). So, that 8/16 little/big endian differences there also not what cause those distortions. Its something else. You may try to run those test cases, maybe you will see something in nova over your debug environment
@kas1e Sorry, but I really don't have the time to be debugging other people's code right now.
All I can say is that the Warp3D Nova driver code handling vertex inputs is pretty straightforward. So long as you're feeding it with floats and have given it the right pointers, strides, etc., it works.
Hello The "quake3 mirror distorsion bug" happen with waZp3d too so certainly is a minigl bug Next week I will try to find what cause it as wazp3d got lots of debugging features
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
