Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / Game Design & Programming / Correct physics + variable framerate Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
mstr99

May 13, 2005, 09:13 AM

I've been thinking about the best way to implement physics, collision checking etc. properly, and it seems that fixed rate would make the calculations easiest. On the other hand video framerate can't always match the physics, so that would give my some twitchiness in animation.

So is there a one best way to solve this conflict, or many solutions with their own tradeoffs? Any help is welcome.

Am I just begging for a brian fellows answer?

 
Danny Chapman

May 13, 2005, 09:23 AM

The best (in my opinion) way is to have a fixed physics timestep. Then, each time you update your main loop you advance the physics system until it just goes _beyond_ the "system" time. Then for each physical object interpolate between it's current and old position/orientation, based on the system and the physics time, and use this interpolated state to render.

If you do this you can run your physics system at a low frequency - e.g. 30Hz - assuming it's stable, and your game looks really smooth even if the frame rate is high. If you don't interpolate then you can get jerkiness due to irregular numbers of physics updates per frame, and due to the fact that even with a high framerate objects don't necessarily move every frame (especially a problem if your camera isn't synced to the physics system).

 
PixelClear

May 13, 2005, 11:23 AM

Hi,

Physic integration and framerate is a tricky problem.

The easy solution always seems to use a fixed timestep. It makes your game quite predictable and your physic more robust. However this has a few caveats that can become nightmares. If you assume your physics is updated at a contant rate your logic will be someting like this :

while (!Gameover)
{
Update();
while (PhysicTime

 
mstr99

May 16, 2005, 02:41 PM

Thanks for interesting points. I've been thinking about possibility of demo recording and playback too, so it seems that fixed timestep should be the way to go?

 
Victor Widell

May 17, 2005, 02:54 PM

You could reckord the deltatime of each frame, so fixed step physics is not a requirement for playback.

 
This thread contains 5 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.