Sign in to follow this  
ms75214

physics loop

Recommended Posts

What do you guys think?
 
Is it better to make a game with a physics loop as a separate thread or not?
 
If it is separate, you could have all kinds of multi-threading issues.  If it's not, you may be losing performance on a multi-core system.
 
Thanks.
 

Share this post


Link to post
Share on other sites

It can be, if you get the synchronization right. But it is certainly harder to implement than in a single-threaded fashion where physics is just another part of the game loop. Also consider that physics processing is slowly moving to the graphics card, so ideally you'd want your game to be able to cope with both situations effectively.

 

So it really depends on your definition of "better". If that translates to "faster", then yes, you would likely benefit from it on multicore systems if you are able to overlap some of your physics processing with game logic and other things that need to happen each frame, but if your physics calculations already take near 100% of your total computational cost (remember graphics rendering is already asynchronous for the most part) then it may not be worth the threading overhead.

On the other hand, if you define "better" as "cost-effective with regard to development and testing time", then it may not be better at all. For instance, it's often said that you don't shoehorn multithreading into an existing code base, which is true, if you want to get something stable and not spend months refactoring it all, you want to start your game implementation with multithreading in mind. Similarly, as mentioned above, if you are implementing a game which doesn't require much processing power at all (think a simple physics-based game like a pinball or those flash games where you knock over castles) then perhaps it isn't worth it to spend time making the multithreading work as you likely won't see any benefit from it on any modern system.

 

So, "it depends". Multithreading can be really, really hard to get right, and sometimes the manpower spent making it work is better spent elsewhere like better content, more features, or bugfixing.

Share this post


Link to post
Share on other sites
To gain from multithreading, you need to be a) doing enough work, and b) need to update the result infrequently.

For a physics system, a is probably satisfied, but unless your fps is very low, b is not. You need to synchronism every frame, and the cost of that is more than the benefit of parallelization.

Share this post


Link to post
Share on other sites

To gain from multithreading, you need to be a) doing enough work, and b) need to update the result infrequently.

For a physics system, a is probably satisfied, but unless your fps is very low, b is not. You need to synchronism every frame, and the cost of that is more than the benefit of parallelization.

 

Do you really need to 'synchronism every frame'?

I think 99.9% of the time things will look fine if you don't synchronize every frame.
 

Share this post


Link to post
Share on other sites

Is it better to make a game with a physics loop as a separate thread or not?

Considering the context of the question --- the for beginners forum --- it is far better to go with the single threaded model.

Developing robust multithreaded code is hard. If you are a beginner you are already spending your time learning many other things necessary for game development. It is improbable that your game will be so compute intensive that a multithreaded solution will give a benefit. No need to throw in all the additional learning and the additional headaches for something that is likely to give no significant improvement.

Share this post


Link to post
Share on other sites

I upvoted frob, as it is likely the most  relevant. Also, you would most likely be better off with a hive of worker threads that can reap the benefits of mt, rather than a single thread to work on physics, which will sit empty the rest of the loop.

Share this post


Link to post
Share on other sites

To gain from multithreading, you need to be a) doing enough work, and b) need to update the result infrequently.

For a physics system, a is probably satisfied, but unless your fps is very low, b is not. You need to synchronism every frame, and the cost of that is more than the benefit of parallelization.

 
Do you really need to 'synchronism every frame'?

I think 99.9% of the time things will look fine if you don't synchronize every frame.

That depends on what needs to be done, but physics code tends to involve collision detection and general movement. You certainly want objects to move every frame, and likely collision behavior will be better if objects can't pass too deeply into each other.

But if there is code that can be updated less frequently, then there can be a benefit to multi-threading.

Share this post


Link to post
Share on other sites

You might also consider using/writing a physics engine that has a multi-threaded implementation. Then you use it in a synchronous fashion from your main game-loop but still reap some of the benefits of multi-threading.

 

As a general rule, multi-threading is a pain in the neck - If you a single-threaded solution is good enough then do that and save yourself the hassle.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this