Irrlicht Engine

New version has the warnings removed. Sadly no speed-up, would have to rewrite XEffects quite a bit for that and I'm not familiar enough with the code to do that.

My guess is you replaced the createSphereMesh by a getMesh() call but still drop() that mesh. Guessing that because that's what regularly happens to me when I switch from createMesh functions to getMesh functions and you'll get exactly that crash then ;-)

Sorry, either I don't get what you do or what you expect. If you move an object left-right in 3D space with perspective camera then objects do change (if you are in a tunnel you can see both side-walls at once because of that). That's what perspective does. You can't move things to the side and have...

COBJMeshFileLoader seems to be in /irr/src/COBJMeshFileLoader.cpp in Minetest (at least in master branch). If you search for S3DVertex there is only once place. And what I mean with - "need corresponding meshbuffer" is that SMeshBuffer _only_ takes S3DVertex, it can't take S3DVertex2TCoord...

In general it's the loader which creates the vertices. Not sure right now if any actually does that. Or yourself if you have your own functions to create meshes. Make sure to use the correct vertex type in the corresponding meshbuffer class. In newer Irrlicht you can use CDynamicMeshBuffer(EVT_2TCOO...

Maybe you are missing some aspect ratio changes? Your first image has 15/8 your second has something like 2 times 7.5/8 (with the images you posted here, I guess real ones are likely not exactly the same). The camera always renders the full height of your given field of view (ICameraSceneNode::setFO...

Nice.I'll get rid of the other warnings on Monday probably (got some public holiday here).

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...