Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualL. Spiro

Posted 04 October 2012 - 02:36 PM

I don't understand how that could work though. I thought the point of this was to make sure that physics ticks at an exact interval.

It is not possible to fix something to an exact interval.

You are misunderstanding that the updates have to be spaced at every 33.33 actual real-life milliseconds.
In fact, inside the simulation, if you made 2 updates of 33.33 milliseconds each, but in 1 case they are done immediately back-to-back, 0.00001 milliseconds apart, and in another case they are done closer to real-world time at exactly 33.33 milliseconds apart, the simulation result is the same.
In either case, you just told the simulation to update 2 times, at 33.33 milliseconds each. How much actual time was between those updates does not matter to the simulation.


With that understood, that means you now understand that you can update any number of times within a single game loop. Meaning if the simulation falls behind real-world time you can catch it up by updating multiple times instead of just updating once by a longer amount of time.
Likewise, if too little time has passed since the last update (as in, fewer than 33.33 milliseconds) then you can update 0 times. Just move on.


The concept should become simple. Updates are always done at a fixed amount of time, and then in order to keep the simulation as close to real-time as possible, each frame you check to see how many times you should perform an update. If you are running at 60 FPS, the every second frame will update 0 times, and every other frame will update 1 time.
If you suddenly drop to 10 FPS, every frame you will update 3 times. This catches the simulation up to the current real-world time without allowing it to go beyond the current real-world time.


Also, when it comes time to render, who does the interpolation, the renderer, or the physics engine? I ask because my system is multi-threaded.

The renderer. Physics won’t updated at an interval fast enough to provide interpolations meant for the renderer. Since they are only meant for the renderer, they should be updated by the renderer.


L. Spiro

#2L. Spiro

Posted 04 October 2012 - 02:34 PM

I don't understand how that could work though. I thought the point of this was to make sure that physics ticks at an exact interval.

It is not possible to fix something to an exact interval.

You are misunderstanding that the updates have to be spaced at every 33.33 actual real-life milliseconds.
In fact, inside the simulation, if you made 2 updates of 33.33 milliseconds each, but in 1 case they are done immediately back-to-back, 0.00001 milliseconds apart, and in another case they are done closer to real-world time at exactly 33.33 milliseconds apart, the simulation result is the same.
In either case, you just told the simulation to update 2 times, at 33.33 milliseconds each. How much actual time was between those updates does not matter to the simulation.


With that understood, that means you now understand that you can update any number of times within a single game loop. Meaning if the simulation falls behind real-world time you can catch it up by updating multiple times instead of just updating once by a longer amount of time.
Likewise, if too little time has passed since the last update (as in, fewer than 33.33 milliseconds) then you can update 0 times. Just move on.


The concept should become simple. Updates are always done at a fixed amount of time, and then in order to keep the simulation as close to real-time as possible, each frame you check to see how many times you should perform an update. If you are running at 60 FPS, the every second frame will update 0 times, and every other frame will update 1 time.
If you suddenly drop to 10 FPS, every frame you will update 3 times. This catches the simulation up to the current real-world time without allowing it to go beyond the current real-world time.


L. Spiro

#1L. Spiro

Posted 04 October 2012 - 02:32 PM

I don't understand how that could work though. I thought the point of this was to make sure that physics ticks at an exact interval.

It is not possible to fix something to an exact interval.

You are misunderstanding that the updates have to be spaced at every 33.33 actual real-life milliseconds.
In fact, inside the simulation, if you made 2 updates of 33.33 milliseconds, but in case they are done immediately back-to-back, 0.00001 milliseconds apart, or if they are done closer to real-world time at exactly 33.33 milliseconds apart, the simulation result is the same.
In either case, you just told the simulation to update 2 times, at 33.33 milliseconds each. How much actual time was between those updates does not matter to the simulation.


With that understood, that means you now understand that you can update any number of times within a single game loop. Meaning if the simulation falls behind real-world time you can catch it up by updating multiple times instead of just updating once by a longer amount of time.
Likewise, if too little time has passed since the last update (as in, fewer than 33.33 milliseconds) then you can update 0 times. Just move on.


The concept should become simple. Updates are always done at a fixed amount of time, and then in order to keep the simulation as close to real-time as possible, each frame you check to see how many times you should perform an update. If you are running at 60 FPS, the every second frame will update 0 times, and every other frame will update 1 time.
If you suddenly drop to 10 FPS, every frame you will update 3 times. This catches the simulation up to the current real-world time without allowing it to go beyond the current real-world time.


L. Spiro

PARTNERS