Irrlicht Engine

Hunting it was a bit fun ;-)

Found the reason now btw, in r3652 (before 1.8.0 release) there was a change which added calls to glDisable(GL_BLEND) and glEnable(GL_BLEND) which started conflicting with the materials settings for disabling/enabling blending. Then later in trunk - it just got set once more afterwards, which on fir...

If you have no reason to stay with Irrlicht 1.8 (and only one I can think of is that you want to use official Irrlicht in Linux distributions like Debian) then I can definitely recommend moving to svn trunk. I've been working with that now for the last decade or so. As for how it works - just update...

CNullDriver::setRenderTarget automatically uses ECF_D24S8 for depth-texture
Actually one of the blocking todo's for Irrlicht 1.9 release.
It might be possible to avoid the error by manually setting another depth-texture.

Hm, don't think I'll have good news for you. Turns out trunk works again. So there was probably some bug in Irrlicht 1.8 release. I'll look a bit if it's something simple, but won't really spend too much time there. 1.8 has lot's more bugs than Irrlicht trunk and I'm only doing some simple maintenan...

Yeah, looking into it. I got 1.8.5 working, but with some wrong results with OpenGL in the first 2 examples. Rest (D3D and examples 3-6) seems to work (with a bit updated project files, and switching to 7.1 SDK). I'll check later some more if I can see why those 2 examples go wrong now (my fork is o...

Getting XEffects running is probably the best way for now. If you say recent versions - you mean getting XEffect to work in svn trunk version of Irrlicht? I think the thread about XEffects had some hints about that (best start reading from the end...). I can also try to find some time to give it a s...

Not seeing it used anywhere in OpenGL drivers. I guess only makes sense for d3d. Might have to do with d3d compiling to assembler earlier than GL so maybe it needs to know it's target, but I'm not sure. I'm a bit confused why it still passes this on to COpenGLSLMaterialRenderer when that one does no...

Hm, I get your problem. Then again it's nice to see if someone did run the tests or when they started failing (which is I guess why it's in there). Or didn't run tests despite changing half the engine... Not sure if we can have both. edit: Oh well, it's a bit useful, but I think merge conflicts are ...

Something I'm still struggling a bit myself. I think you can do that as long as the order is the same as in S3DVertex (or one of it's derivated structs). In OpenGL and GLES1 I usually work with gl_Vertex, gl_Normal, gl_Color, gl_MultiTexCoord0 (to n). This isn't really recommended anymore it seems, ...

Yeah, lot of people just visit for a bit and move on. I wish I knew more about electronics, but for now I'll accept "it's super fast switches for controlling electron streams" or something like that ;-)

The texture warning is still open, but should be last one for now (edit: fixed now as well). And yes - tests have to be run from within tests folder. On Linux this generally means copying the binary first in there. Slightly annoying, but nothing I plan to change for now.

Sorry, just typo, meant r6627 not 72. Also I didn't notice that warnings is triggered by 2 lines so I only had fixed one of them. [r6629] has the other one fixed now (I hope).

Hm, strange - even copy-pasted the line you used for compiling. Usually it's the newer GCC's adding warnings, not removing them ;-)
edit: I made a fix in [r6672] which should remove that warning.

Thanks, I get most as well. Fixed the trivial ones, will have to check the rest. But currently still struggling with another report.

Not getting the printf one btw, I guess Ubuntu has newer gcc version by now than my Debian stable (still gcc 12.2.0 here).