why is the physics engine on a 2nd thread?
Author
why do the new games run the physics engine on a different thread than the game itself does? what is the advantage of it?
take for example Titan Quest. the game even lags in singleplayer. sometimes i can shoot 10 arrows in an enemy and after 10 seconds all get shot at once. this really feels and looks like a lag in d2 on the battle.net...
can anyone explain me why game producers think this is nessecary?
Bacause if it's properly implemented, the performance of the game can be greatly increased. Why have one thread doing all the work, when you can split it on two and reduce the time it takes by up to 30-40%?
Don't blame threading for a supposedly bad implementation/usage in a game.
This describes it quite good.
http://www.gamasutra.com/features/20060906/monkkonen_01.shtml
Don't blame threading for a supposedly bad implementation/usage in a game.
This describes it quite good.
http://www.gamasutra.com/features/20060906/monkkonen_01.shtml
hm, i definitely cant think of ANY area where titan quest has no bugs...
pathfinding, scene-management, rendering, everything is buggy.
examples:
pathfinding: the player gets stuck or runs through the whole screen instead of just going to where i click.
scene-management:
when entering or leaving caves, there is a lag of 2-3 seconds at some pcs
rendering:
the environment looks like displayed on an old tft...
(remember, crts are faster and tfts were very slow thus resulting in artifacts)
this has nothing to do with physics or threads.
mostly physics use an own engine, the data for the physics calculations arent the same as for the graphics. they are simpler, to speed up the physics.
so when the data is not the same, you dont need much synchronization.
on a single cpu system, there is hardly any drawback.
on a multi-cpu system, you have an overall advantage of about 30%
(its not 100% because of the thread synchronization and switching;
also, the calculations for physics and the rest do not take the same amount of time)
pathfinding, scene-management, rendering, everything is buggy.
examples:
pathfinding: the player gets stuck or runs through the whole screen instead of just going to where i click.
scene-management:
when entering or leaving caves, there is a lag of 2-3 seconds at some pcs
rendering:
the environment looks like displayed on an old tft...
(remember, crts are faster and tfts were very slow thus resulting in artifacts)
this has nothing to do with physics or threads.
mostly physics use an own engine, the data for the physics calculations arent the same as for the graphics. they are simpler, to speed up the physics.
so when the data is not the same, you dont need much synchronization.
on a single cpu system, there is hardly any drawback.
on a multi-cpu system, you have an overall advantage of about 30%
(its not 100% because of the thread synchronization and switching;
also, the calculations for physics and the rest do not take the same amount of time)
Quote:Original post by SiS-Shadowman
why do the new games run the physics engine on a different thread than the game itself does? what is the advantage of it?
...
most physics engines require to run at least at a specified rate (often 60Hz or more)to ensure stability. (or else you'd get plenty of fast moving objects not colliding)
if your framerate drops below this rate you have to do intermediate steps to catch up.
putting physics into a seperate thread ensures you can run the physics simulation independantly of your current framerate.
the main (render) loop often spends an awful lot of time waiting for the gpu to finish rendering, especially when ps shader performance is the bottleneck, which happens quite often these days
:)
on a single cpu system i had good results seperating the rendering/physics.
especially in tight situations a threaded approach got away with less intermediate steps than a non threaded.
i hope my answer isn't too messy ;) (english is not my native tongue)
Author
okay, the article makes sense. i didn't think that way *shame*
after reading the article, i think a synchronous parallel model is best for me, because it is the easiest to implement ( i really don't want to change the code at once, perhaps if everything is running correctly ).
i'll have a look at the physx sdk, i hope it suits my needs and that i can understand it well. this will really speed up the creation of my game.
after reading the article, i think a synchronous parallel model is best for me, because it is the easiest to implement ( i really don't want to change the code at once, perhaps if everything is running correctly ).
i'll have a look at the physx sdk, i hope it suits my needs and that i can understand it well. this will really speed up the creation of my game.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
