Should I use SDL with Irrlicht?

[willywilly]

After trying Ogre3D and Panda3D, I decided for Irrlicht because of its incredibly superior coding style and handling.

To my joy, Irrlicht does not only do graphics but also processes input and can open a window to draw into cross platform. The only thing missing for me now are threads. Good old SDL has threads and I know how to use them.

Would it be wise to wrap irrlicht into SDL just for threads? I want to keep my game logic seperated from the user interface, so I can run the game "headless".

[hybrid]

There are also other threading support libraries, which wouldn't come with such a lrage library then. But after all, every threading support should work somehow. Just make sure that the Irrlicht render process stays within the main thread.

[willywilly]

Thank you for the reply!

Why would Irrlicht need to be in the main thread? I wanted to make the game work like this:

Code: Select all

main (containing thread management)
- gamelogic
- - ai
- - netcode
- - scripting
- irrlicht, irrklang (i do not know yet how these are commonly connected)

All connected via a threading backbone I though up which works in SDL for now. But I am guessing that would not be a smart idea. Why? Isn't that how a modern game engine is commonly structured?

Please excuse my probably stupid questions.

[loki1985]

your structure should work. just be sure rendering calls (and any calls transferring data to/from the graphics card) are made in the same thread, since rendering APIs like d3d and ogl are not ready for multithreading.
i don't think it must be the main thread, but it cannot be spread among several threads.