Jump to content
  • Advertisement
Sign in to follow this  

On Time

This topic is 5090 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Can anyone point me in the right direction on some articles that discuss the topic of time when it comes to calculating physics. In my experiments I've implemented time in different ways depending on what I was doing. For each it was specialized for the task at hand and tying those experiments together would not be easy. I'm hoping that somewhere there is some good information on different ways to approach time in real time games and simulations, what their strong and weak points are, and examples of implementation. It seems like this would be covered in a game engine development tutorial or book, but I've been trying to find it in something a little less heavy. If anyone knows off hand any good documents or books that go in depth into dealing with time a point in the right direction would be appreciated. -Corey

Share this post

Link to post
Share on other sites
I don't have a definitive reference for you, but here are some pointers, in stream-of-consciousness order.

1) Decouple the simulation from the rendering and do the simulation in discrete time steps ( ie 16 milliseconds per tick ).

These together make your physics more stable, and testable. As part of this, you will make your game loop take an time argument like so

void Game::Session::Tick( const size_t milliseconds );

also, your rendering probably needs a tick, but not necessarily the same value as the session tick.

void Renderer::Frame( const size_t milliseconds );

The renderer can track the time since it last rendered to do motion trails, etc. This allows an easy freeze frame matrix-like effect.

For consistency, I always work in seconds with my physics.

void Game::Object::Tick( const float32& seconds );

3) Have a game session object that tracks the current time as seen by this game session.

This should be where all game-related things get their time count. Very few places in your engine should ever query the actual system time.
When the simulation is paused, tick is either not called, or called with a zero time value.

Something like the HUD, gui or menu probably needs the real-time clock to do animations.

4) Game events should have a time to activate.

This allows you to ensure events happen in causal order, as well as schedule events for the future.

5) If each game object has its own tick function taking a time parameter, each object could potentially operate in slow or fast motion.

6) Networked games need a consistent time measurement for all clients. Typically the server provides this at connect time, and may periodically update the time.

7) Networked games often benefit from tracking the real-time latency of each client to do prediction and correction.

Share this post

Link to post
Share on other sites
The usual references are David Baraff, Ron Fedkiw, Thomas Jakobsen, Chris Hecker, Jeff Lander. I'd also suggest looking at David Wu's work. These should all pop up readily in a google search, and you should also find direct links if you search the forum archives.

Share this post

Link to post
Share on other sites

I misread your question, :). You might search the forum archives for "frame-rate independent physics" or "physics time step" or similar. Many folks, myself included, believe that using a constant physics time step that doesn't vary with frame rate is the way to go. It certainly makes for 100%, perfectly repeatable results on any hardware. And, sync'ing up with the real game clock so you don't have objects moving fast on fast CPU's, slow on slow CPU's, is quite easy. This is discussed in prior threads, even some in the past couple of weeks here.

Forum member Gaffer wrote a nice article on how to do fixed physics time stepping:

Fix Your Timestep!

Forum member lonesock has written a nice article on Verlet integration using a variable time step that helps make that method more stable when you do choose to use a variable time step. (Actually, without his approach, it is NOT Verlet integration when time step is variable. Traditional Verlet is based, by definition, on a fixed time step.) Good reading, but it is somewhat academic. If you don't want to learn the math, you aren't going to get too far I'm afraid.

Time-corrected Verlet Integration

[Edited by - grhodes_at_work on January 3, 2005 11:42:12 PM]

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!