Irrlicht Engine

Does anybody knows wether Irrlicht is threadsafe on Win32 or not?

I inspected the sources an doesn't found a clue that it is, but I just want to go for sure.

As threadsafe it would be enough for me if one thread is executing the engine while other threads (one or many) are manipulating the scene.

Any expierence?

Thx

Thorsten

It is not threadsafe.

Is really a bad idea to make a graphic engine with threads... but you can make your game in threads... only that the engine must be in one thread...

aigam wrote:Is really a bad idea to make a graphic engine with threads... but you can make your game in threads... only that the engine must be in one thread...

Hmm, I never planned to do this and understanding this right would mean Irrlicht is threadsafe!? Sure the rendering is done with only one thread but changing the scene, etc is done by another thread at ANY time.

You must mantain all the elements of irrlicht in one thread, but you can make all the rest of your code with multithreading.

You must separate all the render engine of your game with the game engine.

Render engine
|
|-game engine thread 1 (player a)
|-game engine thread 2 (player B)
|-game engine thread 3 (IA)

For example...
you must make a bridge between the render and the game engine.

But I recommend you to not use threads... in games is really most optimal to use multi-steps.

What do you mean with 'multi-steps'?

Divide a operation in multiple frames... the ia for example is a good multi-steep proces, you don't need a inmediate result.

aigam wrote:Is really a bad idea to make a graphic engine with threads

This is definitely correct for Hardware accelerated modes (you only have one hardware acceleration, so what should other threads do) but the software renderer would benefit from multiple threads. Probably not as much as common raytracer do, but you should be able to use substantial ressources from a second processor if you are able to split your render target into pieces. Or if you use doublebuffer and have a thread per buffer.

What I'd like to see is a thread on resource loading, where textures/models are drawn with a temporary figure until the real resource is loaded in-- this means resource loading is not blocking which is helpful for large levels where resources have to be loaded and unloaded on the fly.