Mostly const fixes in headers to make it easier for users to have more warnings enabled in static code analysis
Also updating our own rules a bit (kicking some out we won't need yet).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6583 dfc29bdd-3216-0410-991c-e03cc46cb475
Irrlicht generally avoided user pointers in the past, but after trying all kind of ugly workarounds - this is just easier and
not that much downsides really. Tiny speed costs due to additional SMaterial memory size and new comparison tests.
But allows to keep SMaterial alive and useful for a while longer without needing a complete rewrite and it can now be used for stuff like writing PBR shaders.
Using a new interface io::IUserData for this which also allows serialization the user data (that part is untested so far, sorry)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6567 dfc29bdd-3216-0410-991c-e03cc46cb475
No reason to not have several times faster build-times
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6529 dfc29bdd-3216-0410-991c-e03cc46cb475
So far SceneManager always sorted Nodes per render stage.
Now we allow sorting per mesh-buffer per render stage by creating a new node for each mesh-buffer.
It's only supported for CMeshSceneNode so far.
This allows to enable better transparency sorting for meshes which have transparent buffers.
Previously those always got rendered in the order in which they got added and ignored mesh-buffer bounding-boxes, but just used the bbox of the full mesh. Now they can use the bbox for each meshbuffer which can sometimes avoid render errors.
Also depending on the scene this can be quite a bit faster because it can help reduce texture changes. We sort solid nodes per texture, but only per node. So nodes with several textures had a texture switch between rendering each meshbuffer. And those are rather expensive in Irrlicht right now (and we support no bindless textures yet...)
Lastly it's now also used to buffer the render-stage. Checking this twice (once in registering the node and once in render) constantly showed up in the profiler. Which was a bit surprising really, but anyway - now it's gone.
I tried to keep it working for all cases we had before (all kind of situations, like when people may want to call render() outside the SceneManager). But not (yet) supporting the case of changing the meshbuffers (adding or removing some) without calling setMesh() again. Reason is that this wasn't well supported before either (node materials never updated). So for now I just assume people will call setMesh() again when they change the mesh.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6483 dfc29bdd-3216-0410-991c-e03cc46cb475
We had changed that once before in the other direction in svn r421
Reason back then was "Sleep(0) doesn't allow any lower priority threads to execute"
But Microsoft changed the behaviour of Sleep(0) after Windows XP so that's no longer true.
And the costs of it is pretty high - due to this using a timer with a 15ms resolutions it meant not just giving up the thread but it also always waited for 15ms on Windows.
I also replaced a few sleep calls in examples for that reason with yield() calls.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6459 dfc29bdd-3216-0410-991c-e03cc46cb475
