# 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);

i++;
}



Thank you,

Josheir

##### Share on other sites

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 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 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 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 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 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

## Create an account

Register a new account

1. 1
2. 2
3. 3
Rutin
18
4. 4
5. 5
JoeJ
13

• 14
• 10
• 23
• 9
• 57
• ### Forum Statistics

• Total Topics
632638
• Total Posts
3007602
• ### Who's Online (See full list)

There are no registered users currently online

×