Starting from 30 seconds, you can see how textures of the sky start to mirror+copy all the other world's data, and sometime 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.
Then tested it over MiniGL : no issue. Then asking ptitSeb to test it on Pandora : no issue.
The the code for the skybox is pretty small, and all in Source/Environment/Skybox.cpp there:
--- The skybox is wrong. The faces are not the right ones, and some are not shown at all.
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? ---
And as can be seen in the Skybox.cpp, there is lots of "-size", which may cause on ogles2 or on w3dnova that effect.
And as i do not know what it ogles2 or warp3dnova, i dunno where to report it.
@kas1e Some of the skybox' faces are simply not drawn and what you see are remains of the previous frames because the color-buffer isn't cleared every frame. You can see that the full faces aren't drawn, it's apparently not a wrong z-buffer setup or whatever (you can clearly spot the edges of the missing faces). Please put a glFlush(); after line 157 to rule in/out the only theoretical ogles2 issue I can imagine right now. If that doesn't change anything I dare to strongly asume that the problem is elsewhere.
Btw, not only that: some of the faces are not the correct one. Look at the clouds, there are not correct and are cut in the edge of skybox. That why ptitseb think that maybe negative values are wrapped to positive, and some face are drawn in the wrong coordinate (in place of another face) leading to "broken" clouds.
Btw, not only that: some of the faces are not the correct 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).
Quote:
That why ptitseb think that maybe negative values are wrapped to positive
Well, how should that happen? And where? ogles2 doesn't do any calculations at all (exception: current ubyte -> float patcher, which doesn't apply here). Nova only does inside the shaders (I don't count endian conversion). Negation of those floats is really nothing that would just magically happen during ogles2 copy procedures or whatever.
Quote:
And as can be seen in the Skybox.cpp, there is lots of "-size", which may cause on ogles2 or on w3dnova that effect. And as i do not know what it ogles2 or warp3dnova, i dunno where to report it.
This issue looks like it's neither one. Maybe gl4es' quad -> triangle conversion is somehow broken. And no, it doesn't necessarily mean anything that it works elsewhere
Well, how should that happen? And where? ogles2 doesn't do any calculations at all (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 whatever.
I remember in quake3 we have some issues visually at begining where some areas wasn't draw correctly. It can be indeed some shaders calculation in nova itself too.
@Hans What you think about ?:) Should i maybe create BZ for warp3d, and upload test-archive ?
What you think about ?:) Should i maybe create BZ for warp3d, and upload test-archive ?
Not so fast.
I see that two skybox faces are missing, on opposite sides of the skybox. Can you isolate specifically which sides they are? If it were a negative coordinate problem, then I'd expect all the sides with negative coordinates to be affected (basically, all of them). I don't think that messing up negative coordinates would cause what we see.
More likely, GL_CULL_FACE somehow got jammed to on, or the polygon mode is set incorrectly. Daytona's glFlush() after line 157 suggestion was to flush the commands before backface culling is enabled again.
For the wrong texture, Warp3D Nova doesn't randomly pick textures to use. If it's using the wrong texture, then it was told to use that one (or someone forgot to update the bound texture). Have you checked that the skybox images you have on disk are the correct ones?
@kas1e Can you disable every other rendering but the skybox? It's very hard to narrow down such issues given the complexity of all the components involved. A test-case which consists out of a complete game with only a handful of its thounsands of triangles being broken in whatever way is not the best one If you can strip it down preserving the problem, that would be sth. to send over to me.
Additionally (or if you cannot strip it down), you can do the following:
- insert glHint(0,5); after line 157 - insert glHint(0,4); after line 72 - insert glHint(0,3); after line 48 - insert glHint(0,2); after line 41 - insert glHint(0,1); after line 35
Then build and send. This would allow me to take a good look at the issue and would help to rule in/out ogles2 at least. So far, judging from the symptoms, the most likely candidates are the game itself or gl4es, but of course a nice bug in ogles2 or Nova cannot be ruled out at the moment.
Can you disable every other rendering but the skybox? It's very hard to narrow down such issues given the complexity of all the components involved. A test-case which consists out of a complete game with only a handful of its thounsands of triangles being broken in whatever way is not the best one If you can strip it down preserving the problem, that would be sth. to send over to me.
Yeah, will try stripping it down (through that will be not very easy probabaly) , and there is also i have some older source , which have less code, but which have same bug, so maybe that one can be used if nothing come up till that moment.
Quote:
Additionally (or if you cannot strip it down), you can do the following:
- insert glHint(0,5); after line 157 - insert glHint(0,4); after line 72 - insert glHint(0,3); after line 48 - insert glHint(0,2); after line 41 - insert glHint(0,1); after line 35
Then build and send. This would allow me to take a good look at the issue and would help to rule in/out ogles2 at least.
Done, your ftp, lugaru.lha
Quote:
So far, judging from the symptoms, the most likely candidates are the game itself or gl4es, but of course a nice bug in ogles2 or Nova cannot be ruled out at the moment.
Sure it can be only amigaos4 related, but same code works over minigl on aos4 without that bug (the same data files, the same code, etc). Also it works on all other platforms (without gl4es), like win32, linux, macos with their opengl drivers, and it even works over gl4es on pandora. Imho, when it works on 10 targets in all different conditions, then it can't be game (at least, that least possible).
@Hans Quote:
For the wrong texture, Warp3D Nova doesn't randomly pick textures to use. If it's using the wrong texture, then it was told to use that one (or someone forgot to update the bound texture). Have you checked that the skybox images you have on disk are the correct ones?
Its not wrong textures, its drawing of correct texture done wrong. We can be sure they correct ones because when i build the same code over minigl, all works fine then. I.e. two different minigl and gl4es one placed in the root of game, and share same data, minigl one draws all correctly, gl4es one have that issue.
@Daniel Have no luck with those glHint(0,x) things ? I have another idea reading in other topic about minigl-reloaded : try to run over mgl-reloaded that minigl version of lugaru: http://os4depot.net/share/game/action/lugaru-bin.lha.
If of couse it will runs over mgl-reloaded , and if it will, will be very intersting to see if there is the same bug. If yes : then its w3dnova and/or ogles2, if no then we can probabaly rule out ogles2 and warp3dnova (or at least will have something to think about).
OpenGL ES 2 version 2.2 for Warp3D Nova / AmigaOS4 is on my FTP for testers to test now!
Fixed a bug introduced with the turbo version 2.0: one of the new optmized buffer-hashers had a bug which could lead to all sorts of pretty weird behaviour, like geometry appearing at wrong positions or whatever.
The appearance of this bug also depended on your data buffers alignment and size, so generally spoken it only rarely happened, which is why it slipped through. The fix doesn't have a measurable impact on performance.
Thanks to Capehill for reporting and for providing a very nice tiny test program for it!
Yep, that's it for that version Sometimes there's no big story even if the improvement is substantial And no: this is not related to that Lugaru sky issue.
@Daniel 2.2 version fixed also for me those "stripe lines" which arise when i disable glbegin/glend merger in foobillard (if you remember i show you video about some days ago).
FrickingShark and Lugaru problems still there, yeah :) (i tested them anyway , of course! :) )
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
