Jump to content
  • Advertisement
Sign in to follow this  
Josheir

Semi Fixed TimeStep Question.

Recommended Posts

For the following semi-fixed timestep code I am having trouble understanding the following one line.  I could really use a great explanation.

float deltaTime = std::min(totalDeltaTime, MAX_DELTA_TIME);

 

const float MAX_DELTA_TIME = 1.0;
const float DESIRED_FPS = 60.0f;
const int MAX_PHYSICS_STEPS = 6; 
  
const float MS_PER_SECOND = 1000;
const float DESIRED_FRAMETIME = MS_PER_SECOND / DESIRED_FPS;


while (...

float newticks = SDL_GetTicks();
float frametime = newticks - previousticks;
previousticks = newticks;
float totalDeltaTime = frameTime / DESIRED_FRAMETIME;

...

while (totalDeltaTime > 0.0 && i < MAX_PHYSICS_STEPS)
{
  float deltaTime = std::min(totalDeltaTime, MAX_DELTA_TIME);
  
  updates(deltaTime);
  i++;
}
       
    

 

Thank you,

Josheir

Share this post


Link to post
Share on other sites
Advertisement

The code is incomplete, and i never managed to read the fix your timestep article til the end, but i assume the purpose is to prevent updating farther than actual realtime, e.g. we get those deltatimes in the inner loop:

0.16

0.16

0.16

0.05  //  <- our fixed timestep would go into the future, so lets take a smaller timestep instead

... which is usually a bad idea and i'm sure the article mentions this. (You could try the integration example from last post to see you can get very different results when using different timesteps, but there are much worse things happening when physics get more advanced.)

 

So you should forget about semi-fixed timestep and just use constant timestep instead. If your current results are future results, you interpolate them with the old results from the previous update for smooth looking rendering. 

So, assuming above code is correct and it would tell you to update by 0.5 while your target constant is 0.16, update with 0.16 and do this simple math:

float t = 0.05 / 0.16; // = 0.3 so 30% is past and 70% is future

renderPosition = oldPhysicsPosition * (1-t) + currentPhysicsPosition * t; 

 

The article should mention the details (probably at the bottom).

However, the render interpolation is only necessary if smooth movement looks chunky but not if your game easily keeps at target framerate. Updating with constant timestep is what primarily matters.

 

Edit: fixed number typo

 

Edited by JoeJ

Share this post


Link to post
Share on other sites

Do you know or did you read the documentation for std::min( a, b )?

http://www.cplusplus.com/reference/algorithm/min/

It returns the smallest of both a and b, or if they're equal, it returns a.

float deltaTime = std::min(totalDeltaTime, MAX_DELTA_TIME);

So in the above line, deltaTime will never be greater than MAX_DELTA_TIME or 1.0f.  It's basically capping deltaTime.

It would be a lot more helpful for you and us if you let us know what research you've done, what you think the code does and what exactly you don't understand in it.  Right now we're shooting in the dark as to what your actual problem with just that one line is.  The more information you give us on your actual problem, the better we can help you.

Share this post


Link to post
Share on other sites

The while-loop slices totalDeltaTime (the total elapsed time since last iteration through the game loop) into equally sized (i.e. MAX_DELTA_TIME) fixed timesteps but only as long as so much (i.e. MAX_DELTA_TIME) duration is still available. Otherwise only the remaining time is used. That std::min ensures exactly that: Make deltaTime being MAX_DELTA_TIME as long as it fits in, but the remaining time if it doesn't fit. To actually work, a line like "totalDeltaTime -= deltaTime;" needs to be within the while-loop. Also the shortcut "totalDeltaTime>0.0" makes no sense without such a decrement.

Share this post


Link to post
Share on other sites
On ‎12‎/‎25‎/‎2017 at 3:06 PM, Mike2343 said:

It would be a lot more helpful for you and us if you let us know what research you've done,

 

Sorry, I was trying a new style.  

 

Sincerely,

Josheir

Edited by Josheir

Share this post


Link to post
Share on other sites
On ‎12‎/‎25‎/‎2017 at 3:06 PM, Mike2343 said:

Do you know or did you read the documentation for std::min( a, b )?

It isn't the min() function.  It's was my confusion about the constant : MAX_DELTA_TIME.  I was perplexed until haegarr explained.

Josheir

 

Edit:  At least I think I understand:

...Otherwise only the remaining time is used.

Edited by Josheir

Share this post


Link to post
Share on other sites

Suppose you minimize the application so everything stops; 30 seconds later the application is restored.

The counter will now read that you're lagging behind 30 seconds and needs to catch up.

Without the std::min, and depending on how your code works, either you end up calling update( 30 seconds ) which will screw your physics completely; or you end up calling for( int i=0; i<30 seconds * 60fps; ++i )update( 1 / 60 ); which will cause your process to become unresponsive for some time while it simulates 30 seconds worth of physics at maximum CPU power in fast forward.

 

Either way, it won't be pretty. The std::min there prevents these problems by limiting the time elapsed to some arbitrary value (MAX_DELTA_TIME) usually smaller than a second. In other words, pretend the last frame didn't take longer than MAX_DELTA_TIME, even if it took more. It's a safety measure.

 

Edit: Just implement the loops talked by gafferongames in a simple sample, and play with whatever you don't understand. Take it out for example, and see what happens. That will be far more educational than what we can tell you.

Edited by Matias Goldberg

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  

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!