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.
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.
Considering the context of the question --- the for beginners forum --- it is far better to go with the single threaded model.Is it better to make a game with a physics loop as a separate thread or not?
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.
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.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.
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.
