Hello,

I am working on a game engine, and I have come to the point in the development where I want to possibly implement some multithreading. The engine is a C++ engine written for 2D game.
So far the engine has a basic scene setup, OpenGL rendering, a game-object/component setup, Lua for scripting and making games without using C++ at all, and I am in the process of working with protocol buffers for storage and implementing chipmunk for physics simulation and collision detection. As nonsensical as it sounds, I would like this to someday be an indie friendly (free), 2D version of what Unity is for the 3D space.

Since I am implementing chipmunk right now, and it is often recommended to run chipmunk with a fixed time step, I figured it would be a perfect time to get some sort of threading setup to run physics in a separate thread. I know some games I have looked at also move rendering and audio into a separate thread, so I am not against doing that either if it would improve the performance of games down the road.
What I am basically hoping for from this topic is some advice on the best way to move forth. I have been doing some reading and some sources recommend a separate thread for things while others recommend thread pools rather than dedicated threads for physics, audio, video, etc.. I can't really see how thread pools would be helpful for this, to me it makes much more sense to just have dedicated threads.

Some additional questions:

• What libraries would be useful for this? Currently, there is no reliable implementation of C++11 with the std threads, so I am looking to use an alternative. Preferably, not something as heavy as boost, I want to stay as light-weight as possible with this engine. Are things like OpenMP (no experience with it) useful for this situation?
• Is there a "best" way to implement threading for this type of project? To me, the one thread per task makes sense, but I can also see the argument about O(K) and it being hampered on single core systems (did I mention it runs on android and win/mac/*nix?)

I read threw some articles about the subject, and I am still just trying to get an understanding of this all.

Maybe starting off by putting threads into the engine I have now is a bad approach, but I have always been the dive in type. And I know the saying is to make games not engines, but I am really not that interested in making an actual game at this point in time. The game I want to make at some point in the future, well, it just isn't the right time for me to start working on it right now.

Thank you for any input! I am really just looking to learn.

I too am getting into threading. You really have to ask yourself how necessary it is. For a 2D game, I'd say it might not even be that necessary and you'd be better off sticking with single threaded...

Modern 3D engines do a lot of complicated work that benefit from multicore so I'm looking into it for my engine. It sounds like it's going to be a lot of work so I wouldn't recommend it unless you feel that you truly would benefit from it somehow. 2D games don't require nearly as much processing power as 3D games so I'd probably stick with single threaded. It also depends on the kind of 3D game, and not every 3D game really would benefit from threading either.

Here's a link that gave me some great ideas.
http://software.inte...el-game-engine/

You basically need to avoid just locking all the time or else the engine is effectively single threaded. This means no global shared data. Systems have to pass messages to each other. This is where things get REALLY complicated and hard to debug if you forget to pass certain messages.

Thanks for the link! Looks very useful.

And it may not be needed being only a 2D engine, but I don't really know the requirements of the games I want to make with it yet (for better or for worse) so I am just trying to give it as much strength as I can.