Check from 0:50 , there i went to the roof and look at the sky. You can see that sometime, the effect which looks about the same as in Lugaru arise : same bounds of textures, sometime even empty ones..
What is interesting, in both cases and in Lugaru and in RCTW its "sky".
There is also another bug:
Starting from 0:05, on the floor can be visibly some white dot's lines (probabaly finals/starts of some textures closed together)
Same effect on the wall on 0:20, then on 0:35, then on 0:42.
Check from 0:50 , there i went to the roof and look at the sky. You can see that sometime, the effect which looks about the same as in Lugaru arise : same bounds of textures, sometime even empty ones..
Hmmm. Not sure that's the same. In Lugaru the faces on two sides are always missing, whereas in RCTW it looks more like a face culling algorithm is getting it wrong.
Quote:
Starting from 0:05, on the floor can be visibly some white dot's lines (probabaly finals/starts of some textures closed together)
Same effect on the wall on 0:20, then on 0:35, then on 0:42.
Does it look the same as the lines we used to see in Quake 3? Any chance you can isolate the shader that's responsible?
Then yes, looks kind of the same. At least size of line for sure the same, but in q3 it was about lighting beems only, but there is on floor and on walls and dunno if light is guilty there (but can be of course).
Quote:
Any chance you can isolate the shader that's responsible
Oh.. Not sure how to do it. Gl4es for sure generate lots there, and how to know which one is related, and is it vertex or fragment one which is guilty, and if it shaders at all.
For me most important to deal with Lugaru issue and that long-waiting bug about sampler-function-parametr, which is critical, as while ptitseb is still help , he start to loose interest to help to port one big title as without fixing that bug we cant continue :( is that one hard to fix in compare with others ?
ps. Btw, was you able to fix optimisation errors when compile endian conversion code ? As if it forgotten i can create a bugreport for
The quake-3 seams were caused by the fragment shader. The GPU has this thing called "whole quad mode" that needs to be disabled at certain points for texture-mapping to work correctly.
Quote:
For me most important to deal with Lugaru issue and that long-waiting bug about sampler-function-parametr, which is critical, as while ptitseb is still help , he start to loose interest to help to port one big title as without fixing that bug we cant continue :( is that one hard to fix in compare with others ?
I tried to fix that one yesterday, but it's going to take me a bit more time.
Quote:
ps. Btw, was you able to fix optimisation errors when compile endian conversion code ? As if it forgotten i can create a bugreport for
Yes, it'll be in the next version. I haven't tested the performance change, though, so I'll be interested to hear what impact it has.
Hmmm. Not sure that's the same. In Lugaru the faces on two sides are always missing, whereas in RCTW it looks more like a face culling algorithm is getting it wrong.
At some parts yes, 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. It's really not that far away from the Lugaru symptoms at all, may well be (likely IMHO) the same issue or the same combination of issues.
Quote:
Yes, it'll be in the next version. I haven't tested the performance change, though, so I'll be interested to hear what impact it has.
Please make sure to send me that version asap. Because I finally want to get rid of those workarounds in ogles2 asap - but only if performance is actually better
@Hans,Daniel That issue with Lugaru and RTCW for sure can't be issue with wrong datafiles, as its the same datafiles which used on other platforms, and what more important, if i build minigl version of Lugaru which use exactly the same datafiles, everything fine.
What is intersting to understand, is that its some general code issue anywhere, or it is some shader fails to work as expected..
Probably better (and more easy) will be to fix Lugaru's one, and then check if it will automatically fix RCTW , because RCTW is for sure harder to debug.
Also that what ptitseb says about when watch RCTW video :
Quote:
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.
@Raziel If it minigl, then its better go to minigl thread to avoid another sub-thread there (which will make harder to concetrate on gl4es and co).
Also if it minigl working over Warp3D SI , probabaly worth to try the same app on the same place over minigl over warp3D working on radeon9250 or so, to see if there is issue still. And if yes, then its minigl. If no issue on radeon9250, then can be SI driver related probabaly
That issue with Lugaru and RTCW for sure can't be issue with wrong datafiles, as its the same datafiles which used on other platforms, and what more important, if i build minigl version of Lugaru which use exactly the same datafiles, everything fine.
Yes, you said that earlier.
Quote:
What is intersting to understand, is that its some general code issue anywhere, or it is some shader fails to work as expected..
Probably better (and more easy) will be to fix Lugaru's one, and then check if it will automatically fix RCTW , because RCTW is for sure harder to debug.
Could you disable all rendering except for the skybox? Then maybe you can log the GL calls used to render just that item.
Also, have you isolated the shader that's used for the skybox? I'm doubtful that it's a shader issue. The skybox's shaders should be pretty simple.
Could you disable all rendering except for the skybox? Then maybe you can log the GL calls used to render just that item.
Will try
Quote:
Also, have you isolated the shader that's used for the skybox? I'm doubtful that it's a shader issue. The skybox's shaders should be pretty simple.
ptiSeb also says it probabaly not shader, but some precision (loss) somewhere (because depending on the angle, the far edget of the poligon is "too far"), or the order of the draw command that makes a difference.
reviving my sub thread from here (shader compiler error)
I tried the workaround with setting a version tag and this is what i get: Quote:
In GLSL, the version tag is not mandatory, with #version 110 being the default. So at the very least the OpenGL driver maintainers on AmigaOS4 should be notified their implementation is not compliant with regard to this issue.
We could explicitly set the version on all platforms (for OpenGL ES2 the default is #version 100, 110 is invalid). However, a variable named g_precisionDefines is maybe not the best place to do so...
Our ogles2.library contains a patcher for GLSL when the code doesn't contain a version tag. The internal (reference) GLSL-to-SPIR compiler would not compile texture2D and some other stuff in such a case.
It is true that the standard says that if you leave out #version then it defaults to 1.10. However it is also true that the standard says: "... then it assumes 1.10, which is almost certainly not what you want." It is also true that the lack of a version tag is most often not because the coder wanted it, but simply because the coder forgot to put it there.
That's why if the version-tag is missing, the library patches some typical function names. It's just a simple string replacer and the compiler is obviously not smart enough to cope with a variable that's named like a function ("texture" in your case).
Three solutions:
1. fix your GLSL code by providing an explicit version-tag as I told you in the other thread.
2. disable ogles2's internal GLSL patcher by providing OGLES2_CCT_SHADER_COMPAT_PATCH, FALSE when creating your context.
3. wait for opengles2.library 2.3 , because for that one I just modified the patcher's behaviour: if the patched result fails to compile, then it will silently try again using the unpatched variant.
Edited by Daytona675x on 2019/3/25 15:18:28 Edited by Daytona675x on 2019/3/25 15:19:03
@Daniel,Hans I take the older Lugaru's sources (they a little bit smaller, while still have the same issue with gl4es while no issue with minigl), and strip it down heavy : 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).
So it's actually three of the 6 skybox faces that are missing. Interesting...
Any chance you can get us the vertex shader code?
EDIT: Just looked at the Lugaru skybox code again, and I still don't see how a shader calculation bug could cause that. Each of the missing quads shares vertex coordiates with two of the visible quads.
@Hans Yeah, will dump all shaders too, just tring to reduce it even more.
Also glcalls related to the skybox can be also not only in skybox.cpp, i mean, in the GLSceneDraw(), skybox.draw called just one time, but before and after there lots of other glcalls , i.e.:
Will try to reduce it even more now, and dump all the shaders. (today ptitSeb add another ENV variable to gl4es, which make it easy to dump shaders, without needs to hack the code all the time with prinfs).
EDIT: and what is interesting, if checking carefull gl4es version video, then you can see that when we only run, some faces have copy of the previous screen (the same, as we have in RCTW Reboorn as well). I.e. chances are high that it the same issue.
1) Starting in window mode makes mouse cursor break (starting in fullscreen does not break the mouse, but ... see below) 2) Starting a game that opens it's own UI box, before going into the game itself, makes the background go nuts (not erased, should be black normally), instead it takes something from an earlier adress (it seems/i think/i believe) 2.1) If i click cancel in that box to return to the launcher/list screen, the mouse is now broken as well. (see 1)
Switching to fullscreen or back to window will "fix" the cursor. I think i know why the cursor in fullscreen is initially fine. It's because even if i start in fullscreen a window (filled black) is drawn first before it opens the screen. This window to fullscreen switch is sufficient to "fix" the cursor in initial fullscreen
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
