undefined | Better HN

0 pointsmeheleventyone4y ago0 comments

The simulated time is incremented by 16ms per inner loop a roughly 60hz rate. You’re correct that the simulated time catches up to the real time. Just wrong about the number of sub-steps and how the timers proceed. Technically Fabian’s solution will likely run slightly ahead of real time because of the inner loop condition.

You do get jitter from a changing number of sub-steps per variable step which is why you want to do things like the interpolation in Glenn’s solution. This is also why you still want to do everything in your power as a game developer to reduce the variance in real step size.

0 comments

4 comments · 2 top-level

certeoun4y ago· 2 in thread

> The simulated time is incremented by 16ms per inner loop a roughly 60hz rate. You’re correct that the simulated time catches up to the real time. Just wrong about the number of sub-steps. Technically Fabian’s solution will likely run slightly ahead of real time because of the inner loop condition.

Can't the inner while take 1 ms or 1 ns for an iteration? I don't see how the inner while's execution time is at roughly 16 ms. Okay, if my number of sub-steps is wrong, then I am really missing something here. Just trying to understand what exactly is wrong with my thinking.

It is supposed to be so simple, yet I have real trouble understanding it currently. I am basically stuck now.

meheleventyoneOP4y ago

The inner loop can take as little time as it likes to actually do the update but it is accounted in simulated time by adding 16 to the timer and accounting for that in the update by passing in 16 as the amount of time to update for.

Real time is updated once at the start of the step then simulated time catches up in 16ms increments. So you get as many update calls as there are 16ms increments to simulated time before it exceeds real time.

This is all very simple but also pretty finicky to think through. I’d replicate the code in the language of your choice and step through it.

certeoun4y ago

I think I finally got it now. I set myself up with roadblocks preventing me from seeing the tree in a forest. After learning what delta time (and variable timesteps) are, I finally understood what the core issue (frame rate independence) is and why you need a fixed timestep for it.

account424y ago

> This is also why you still want to do everything in your power as a game developer to reduce the variance in real step size.

Well the main reason is that for either variable time slices or fixed time slices with interpolation, what the time for the simulation/interpolation you want is that for the current frame, but you don't have that until you render it. So what you do is assume that it will take about as long as the previous frame, which is a bad prediction if the frame time variance is too big. If you really want to eliminate the jitter you'd need to simulate/interpolate for a time that you are guaranteed to be able to render the frame in and then make sure that the frame is displayed when that time elapses and not before. This of course increases latency so there is always a tradeoff.

Another cause for jitter is that even measuring the time between two successive frames can be difficult with modern GPUs - the CPU time at the start of the game loop doesn't really cut it: https://medium.com/@alen.ladavac/the-elusive-frame-timing-16...

j / k navigate · click thread line to collapse