@Georg Probably 0xabadcafe flying there as i on debug kernel + munge enabled in. Anyway that all looks quite strange, like some stack-data--pointer overflow
In meantime will try to print out indicies in lettersfall game (which works, but have trashing), maybe its all about one problem in end.
edit: lettersfall use glDrawArrays only, and there no indicies to print. Anyway probably only roots of problems in neverball will be found, will be clear how to deal with all others problems (probably).
But what we also tried, its to add to gl.c , at line 1065 the line if(indices && indices[0]>0x2000) printf("Too late...\n"); And, before crash we have that "too late" thing, which dunno, somehow point on race condition maybe ?
@All Issue with neverball/neverputt was because of gl4es: it crashes even on other platforms (damn). So gl4es guy fix it: "Fixed a nasty bug when merging drawlist inside a glList and no indices were present".
Now neverball and neverputt both runs fine. And, by FPS it is faster in 2-3 times than minigl version. For example first stage in neverball, in minigl version give 58 fps, in gl4es one give 150fps. In some other hardcore by details level, minigl version give 9fps, gl4es one - 22fps. Dunno why there is faster (in compare with let's say, quake3), as both games use glBegin/glEnd route. But code different anyway, so eveyrthing possible.
Also in MiniGL version in both neverball and neverputt , there is sometime visuall glitchs and "blinks", while in gl4es version on the same places , all renders correctly.
But in end, not fix for neverball, not removing arrays from stack make no fixes for cadog test case and letter's fall textures trashing in menu, sadly :(
In neverball log: indeces 43949,51966 -> 0xABADCAFE
LOL
@kas1e Quote:
Issue with neverball/neverputt was because of gl4es: it crashes even on other platforms (damn). So gl4es guy fix it
Great! But why "damn"?
Quote:
Now neverball and neverputt both runs fine. And, by FPS it is faster in 2-3 times than minigl version.
Aha!
Quote:
Dunno why there is faster (in compare with let's say, quake3), as both games use glBegin/glEnd route.
Maybe neverXXXX uses display-lists which probably results in a less inefficient render-path inside gl4es (or maybe he even uses VBOs then?). Did it also fix Q3?
Quote:
He also for sake of remove from list.c arrays on stack:
I don't think this is wise. The stack-allocated index array shouldn't be an issue by itself (unless the stack is too small of course, but I suppose we can rule that out) and it's much faster than the fastest malloc. This is the typical "a crash symptom appeared at XYZ, so let's change XYZ"-tactic he should definitely avoid! So unless he found a true bug there, he should better revert it.
I was in hope that its all about probems and with cadog test case, and with letters fall trashing, and with quake3 / irrlicht, but as it didn't help anywhere, but only in neverball/neverputt, then damn, as it mean again we on the same point as 2 weeks ago called "we do not know where to find roots".
Quote:
Did it also fix Q3?
He say this issue was very specific: you need to have glList for it to trigger. Other games doesn't used them probably, so it will not fix our issues.
But i anyway do test it of course, and nope, all the same as we have before. But with neverball/neverputt he reproduce it on his side, so it was easy, while other issues he can't reproduce.
In other words we again on the same place called random-unknown-shit :)
@Daniel Btw, did you checked irrlicht example ? There is also 2 verions hacked and non hacked, and issues are the same as in quake3. Maybe it will give some more info in compare with just q3 ?
Probably 0xabadcafe flying there as i on debug kernel + munge enabled in.
Btw, in case the clib uses it's own special routines for malloc + co. (instead of just Exec memory/pool functions) then mungwall like memory tool may not be able to track each and every single malloc'ed memory.
This may hide errors which such tools can detect, so sometimes for debugging things it helps to temporarily have in your code your own very simple implementation for malloc/calloc/realloc/free which simply map to AllocVec,FreeVec(),CopyMem(). Just put your replacement function somewhere in the source and that should be enough to cause the clib ones to be overriden (at least with static clib).
Can you just write Validator, that check if the content of the table is correct, and report where it gets broken with printf() and pause it with getchar();
@Georg I build all with newlib, but yes, you are right that not all mungwall tools works the same. For example munge functionality of debug kernel do not catch everything, not from clib2, not from newlib. While when you add memguard at top, it can catch much more and not only from clib2 ones, but from newlib ones as well (which is strange, as menguard kind of dated). Through currently cant use memguard on x5k, as it hits a lot to some system component, so until that fixed cant use it.
1). We found some issue in the shader related code in NOVA (false assign of some alpha components to wrong values): http://amigadeveloper.com/bugreports/view.php?id=318 But, even if it will be fixed, that probably not related to the trashing issues in letters fall, that strange issues in cadog-cutoff-test, and with issues with quake3 & irrlich engine.
2). Now as i can do nothing more about, i will setup some ppc linux on my x5k, compile some glES emulator (software mesa one probabaly), and will check gl4es on linux. By that we can (or can't) rule out issues with big endianes. If any of issues we have on os4 now will be on linux too: then gl4es need more ppc fixes , if not, then it will mean our side (nova, ogles, sdl, my dirty hands or whatever else).
3). We also can wait till nova will have support of arrays in the shaders, then, i may try to use Regal too, to see, if it will possibe to compile the same games , and if they will or will not behave the same as gl4es in term of bugs. But that of course "if", as it needs nova-with-arrays , and no one can be sure that Regal is matured enough to run those games we run over gl4es.
At this moment that all about what i can think of.
@All Some news: Hans fixed issue with q3 when we look at mirror , as well as added OpSelect to shaders (so, more stuff works over gl4es with it).
@Hans Btw, if you do check quake3 test archive, you may notice that once we walk to any place of any level where we have sky, then the sky is overlap some parts of levels's textures.
I made short video to show issue (sorry for low phone quality):
I show that video to gl4es author and reask if he didn't have that issues with gl4es on his platforms, and he say that all good on his side and it looks like some precision issue with the Depth buffer. Also he say that quake3 render sky first thing, than the other stuff are renderer on top of it. The sky is supposed to be far away, so maybe there is some loss of precision in the depth buffer with the sky values.
He also point out where all the Sky function in quake3 and the actual drawing and so i can from my side add some printf (of s_skyPoints[t][s]) to see what kind of coordinates are used for the sky, which may help finding the issue.
Btw, if you do check quake3 test archive, you may notice that once we walk to any place of any level where we have sky, then the sky is overlap some parts of levels's textures.
I made short video to show issue (sorry for low phone quality):
I show that video to gl4es author and reask if he didn't have that issues with gl4es on his platforms, and he say that all good on his side and it looks like some precision issue with the Depth buffer. Also he say that quake3 render sky first thing, than the other stuff are renderer on top of it. The sky is supposed to be far away, so maybe there is some loss of precision in the depth buffer with the sky values.
To me it looks like there's a clipping plane set that shouldn't be there, or the skybox is somehow not rendered in the right place. Or, is the depth-buffer mistakenly left enabled when rendering the skybox?** No idea how the Q3 code works but, when a skybox is rendered first it makes sense to disable the depth buffer entirely because the skybox is supposed to be infinitely far away (i.e., all pixels remain at the zfar value you cleared it to).
Quote:
Should i create BZ about as well ?
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).
It does NOT look like a depth-buffer precision issue to me.
Hans
** NOTE: There are two states controlling whether the depth-buffer is enabled: - Enable/disable depth testing - Enable/disable writing to the depth-buffer I expect that writing to the depth-buffer should be disabled when rendering the skybox... unless rendering the skybox is used to clear the depth buffer (in which case depth testing will be disabled or set to "always")
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
