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 :)
@Hans Yeah of course, passed :) He have no amigaos4, no machine for, not that he was paid even 100$ for all that work (not mean that any of us there for money, of course), so i also doing donations to him from time to time and for now making another one. Just so he see that we all apprecated his help.
And you with Daniel deserve it all as well. In terms of graphics support only real things coming from you both today.
I don't know how clever those GLSL compilers are, but it seems to me that it might be possible to discard the fragment before texture is sampled and color multiplied.
Quote:
void main() { vec4 fColor = Color;
if (floor(fColor.a*255.) <= _gl4es_AlphaRef) discard;
Disassembly of crash site:
02431DC8: 4BFFFFBC b 0x2431D84
02431DCC: 813F0028 lwz r9,40(r31)
02431DD0: 3D290001 addis r9,r9,1
Because this one i got just now. Every time i hit an enemy the game crawls down to a near stop only to play along afterwards, after five or six hits, the crash happens.
Every time i hit an enemy the game crawls down to a near stop only to play along afterwards
That only at begining, because gl4es generate shaders for every state, and there is no precompiled shaders support in gl4es at moment. Once you play a bit in first level, you can then exit/go again to, and all will be fine.
To fix those "pauses" fricking shark's shaders need to be working , and as i aware from mantis, Hans already fix it in 1.64, so when that one will be ready for beta, i can check if shaders work, and can then reupload version with enabled shaders.
As for crash itself, nope, first time see it. The crash about which i told are not happens in fricking shark uploaded on os4depot as i disable that functionality : i.e. it possible to press f4, to have stats such as fps and co, and so, once i enable it, and die or pass the level, then it crashes (crash skippable), and in the logs somewhere come strange 0xffffffff (end of memory) , which we currently don't know from where (need ogles2.library debug build which will printf VA,DBO, and whatever which can help to debug it). For os4depot upload "f4" do nothing, to avoid that crash for users.
@Hans Just bring it here as that can be and gl4es related in end, so to discuss it in full all together : its about bug 388 (stride 0). With beta 1.64 it start to behave different.
If before it was something like:
WARP3D_SI.library: ERROR: Interleaved arrays with different strides detected in VBO 0x00000000
Then now, its :
W3DN_SI.library (0): ERROR: Interleaved arrays with different strides detected in VBO 0x65F69630. W3DN_SI.library (0): ERROR: Interleaved arrays with different strides detected in VBO 0x60CDD230. W3DN_SI.library (0): ERROR: Interleaved arrays with different strides detected in VBO 0x60D05930. W3DN_SI.library (0): ERROR: Interleaved arrays with different strides detected in VBO 0x65F64830. W3DN_SI.library (0): ERROR: Interleaved arrays with different strides detected in VBO 0x60CFC430. W3DN_SI.library (0): ERROR: Interleaved arrays with different strides detected in VBO 0x60CE6830. W3DN_SI.library (0): ERROR: Interleaved arrays with different strides detected in VBO 0x6338FD30.
and so on.
Should we reopen ticket 388, or, it need to be discussed before and then created another one ? (if it will be Nova in end)
@Hans What i mean, is that maybe fix somehow related to that ? Because with 1.63, i didn't have anything of that sort, only everything about VBO 0x00000000. But with 1.64, nothing about VBO 0x00000000 but all about other addresses.
Like issue still the same, just values changes.
I mean, should't those errors be there on serial with 1.63 as well, and not only about 0x00000000 ?
I may have also fixed the debug message so that it correctly print's the VBO pointer (i.e., the 0x00000000 was wrong).
Either way, the zero-stride issue has been fixed, so if you're still seeing that error then you really do have interleaved arrays that collide with one-another.
@Hans Mmm.. If it was just wrongly printed VBO pointers then yeah, issue still here and need invistigate. Will try with ptitSeb a bit more then, thanks.
As for RTCW Reborn and those "lines" : sadly i can't catch shaders there, as Huno build it with some older gl4es , but dumping of shaders via environments was added just few days ago, so probabaly we need him to build RCTW with latest gl4es, and then can make more tests..
Good evening, Excuse me but at the moment I work on the new functions of the EGL_Wrap lib and I have not finished incorporating the fix after what Kas1e pointed out to me but it can be used to test the new functions of ptitSeb for the shaders. for information I block on a lot of things because I have never received the latest updates from NOVA, yet I wrote several times matthew but without answers, I can not evolve at the same time as you, however have access to the lib opengles happily. I just put on ftp my executable and the beta currently being created from EGL for you to advance in the rtcw shaders. HunoPPC
@Kamelito, No I do not think (had less I hope not to be wrong saying this ) just there must be a reason but I do not know and I expect his response in private message A new version will be available for all users and there will be glu and glut support complete with the gl4es of ptitSeb with the help of Kas1le I added a lot of new features and new demos to show how the library works and especially the performance
@Hans With new rebuild from Huno with latest gl4es i was able to catch shaders which is used in the level where we have those strange lines/dots on the walls and on floor.
There just 5 pairs of shaders, they all generated right once i load level (all 5 pairs), and then while you play in level no shaders generated anymore.