At least one problem i can for sure 100% reproduce there : is what Petrol say, when i tried with 2.23 use force (via pressing f1 after training level) , then with 2.23 it always crashes/lockups, and with 2.20 never.
So, i use debug build with -O2 of 2.23 (only -O2, not other flags to rule optimisation out), and got nice crashlog:
Seems that dstBytesPerRow parameter is uint32, so code looks suspicious.
Looks okay to me. A bit uncommon maybe but okay. First rInfo.BytesPerRow is being negated ( = very large uint32 which effectively results in a decrease per row during copying, to flip the data vertically), then this is undone when returning.
1. OpenJK with MGL 2.21: player-shadow vs. sabre-lighting-on-floor: z-fighting. According to ddni also happens with 2.20, so let's forget about that for now. Probably even a pure game issue.
2. OpenJK with fresh MGL: stripes in sabre-lighting: at first glance I thought this was z-fighting. But taking a closer look the player's shadow doesn't seem to suffer from this! But in (1) we saw it fighting with the sabre-lighting! So if it was z-fighting I'd expect the shadow to behave similar. But it doesn't. Here it seems to be stable and fine in contrast to the sabre-lighting.
So IMHO there's sth. else going on here. Not to mention the complete vanishing of the sabre-lights sometimes. Very weird.
EDIT: is this changing the picture (incl. that one eventual force crash in OpenJK as reported by kas1e and petrol) for anybody who suffers from the issues? http://www.goldencode.de/tmp/mgl.zip
EDIT: is this changing the picture (incl. that one eventual force crash in OpenJK as reported by kas1e and petrol) for anybody who suffers from the issues? http://www.goldencode.de/tmp/mgl.zip
Crash still there for sure. Reproducable from first try.
Is it possible for you to build 2.22 one ? I can't rollback to see that code via web , but at least we will easy understand if issues with crash start to happens with changes done between 2.21 and 2.22 or between 2.22 and 2.23. That will reduce questions for sure.
Also the same 2.22 can be tested and for jedi as well.
mgl 2.21 , 2.22 and 2.23 : crash mgl 2.20 : no crash
Changelog after 2.20 till 2.21:
Changes in v2.21
----------------
- glGet*() now returns the value of GL_BLEND_DST, GL_BLEND_SRC, GL_COLOR_CLEAR_VALUE,
GL_STENCIL_BITS,
- GL_ALPHA8 and GL_LUMINANCE8_ALPHA8 are now recognized as valid internal formats
- Added missing stub for glGetPointerv()
- Added fake VBO support. For source code compatibility only, the buffers are stored
in the system memory. New functions: glGenBuffers(), glDeleteBuffers(), glBindBuffer(),
glBufferSubData(), glBufferData(), glGetBufferSubData(), glMapBuffer(), glUnmapBuffer(),
glGetBufferParameteriv()
- glTexEnvi no longer sets GL_INVALID_ENUM unnecessarily when multitexturing is used
- Fixed glCopyTexImage2D and glCopyTexSubImage2D with GL_RGB textures
- glTexGenfv() now supports GL_EYE_PLANE
- Added S3TC texture compression using the S2TC compressor. Supports all of the S3TC,
DTXn and ARB formats
- Fixed glCopyTexImage2D()
- Added GL_DEPTH_COMPONENT support to glReadPixels(). Only supports GL_FLOAT type
- Added support for the GL_INCR_WRAP and GL_DECR_WRAP stencil ops
- glTexSubImage2D and glCopyTexSubImage2D now work on mip levels larger than 0
- Added support for the GL_ARB_vertex_array_bgra extension
There i see "- Fixed glCopyTexImage2D()" , maybe that one related. Is it possible in SVN to see when that commit was done, and what exactly was changes (so, will be possible to understand wtf) ?
@all Alright, because one of the issues seems to be very old and because for the other there are sometimes somehow contradicting reports / sth. that seems to be even hardware related and because the "let's make reasonable asumptions and try"-approach didn't lead to a solution until now, I'm now going to tackle that problem with hard math - with binary search
@all Please forget everything else and only do the following: download the latest http://www.goldencode.de/tmp/mgl.zip and try the libs inside its 506 subfolder with OpenJK only. Please tell me the following (and only the following, please let's focus, keep your posts free of anything else please):
1. your specs (model and gfx-card for now) 2. the lib-folder number (506 in this case) 3. does it crash when using the force? 4. is the sabre-lighting looking like a) this or like b) this?
@Daniel Can't answer exactly as you want, as with that 506 version, whole Jedi broken by look, and it was almost unpossible to find a "load" button, but i was able to do so, and it still crashes when i use force. And i can't answer there on question 4, as everything in visuall glitches, so can't see.
@ddni Retest about crash again (few times) , it still here for sure. Also how you check sabre light, if , in that 506 version no textures visibly , i even can't light of saber itself, taken aside checking if it a) or b) :))
Thanks, guys. No, textures aren't gone on my purpose It's apparently simply what this mgl repo rev. produces. Looks like this was one which was totally broken Then let's go one binary-search step nearer to 2.20. I will prepare a new archive asap and tell you when done.
@kas1e Can you please upload your OpenJK to my ftp? The version I got doesn't work at all.
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
