Why use an integration for a fixed timestep game loop? (Gaffer at the games)
http://gafferongames.com/game-physics/fix-your-timestep/
http://www.koonsolo.com/news/dewitters-gameloop/
In the latest game loop from Glenn Fiedler Fix Your Timestep! article, it uses a refresh cycle that promotes the game logic with a fixed delta time. Since the delta time is fixed, why is it integrating based on the delta time? In a fixed game based on timestep, movement cannot be simple:
if ( keyboard pressing "W" ) {
velocity += acceleration
}
position += velocity
instead of passing in delta time varaible:
if ( keyboard pressing "W" ) {
velocity += integrated(acceleration, delta_time)
}
position += velocity * delta_time
Since the delta time in a "fixed" timestep loop has no purpose, it would be like multiplying by only 1. In a "variable" timestep based game, you would need to use delta times and integrate to move, but in this case it does not. values. Note that the variable for delta time is set to a constant and never changes, the game logic is already deterministic and you don't feel like you need to multiply the speed and acceleration by delta time anywhere in the code. What I took away from the article was “Fix your timeline!” As the name suggests, so you have deterministic game logic, not in terms of floating point inaccuracies and exploding physics that comes with variable timestamps. I was just confused aboutwhy the delta time is being passed to the update function as it seems to contradict the purpose of the article. Both articles actually make the same argument against delta times.
double t = 0.0;
double dt = 0.01;
double currentTime = hires_time_in_seconds();
double accumulator = 0.0;
State previous;
State current;
while ( !quit )
{
double newTime = time();
double frameTime = newTime - currentTime;
if ( frameTime > 0.25 )
frameTime = 0.25;
currentTime = newTime;
accumulator += frameTime;
while ( accumulator >= dt )
{
previousState = currentState;
integrate( currentState, t, dt ); // integration
t += dt;
accumulator -= dt;
}
const double alpha = accumulator / dt;
State state = currentState * alpha +
previousState * ( 1.0 - alpha );
render( state );
}
deWiTTERS last game loop does the same: fixed timestep, interpolate rendering, skip transfer. However, he does not mention integration like the other.
source to share
Assuming the acceleration increases or decreases linearly with time, you can change the base speed at average acceleration
Δv = (a0 + a1)(Δt)/2
If the game includes factors such as aerodynamic drag, then the acceleration is affected by the ^ 2 speed, and usually something like Runge Kutta 4 is used to update the speed change and position change for each time step.
My impression is that most PC games use an independent fixed frame rate for the physics engine, which is ideally frame rate independent. For these games, even if the display is sluggish, the actual game is the same as long as the player can deal with the visuals. I've seen older racing games get this right where the graphics performance doesn't affect physics, and newer racing games where lowering the graphics settings improves game performance, which is a bug.
Link to Windows example code to run a stream at almost any reasonable fixed frequency without drifting over time.
In MSDOS days, since the computer runs a timer at (105/88) Mhz = 1.19318 MHz, games use it as a high precision counter.
source to share
The reason it does it in a more complex way is to decouple the physical simulation frequency from the render frequency. So you can display at a variable frame rate (120 FPS, 60 FPS, etc.), but still update the game logic and physics at a constant rate.
One of the advantages of this is that the game logic will behave the same regardless of FPS (many older games will be buggy if you run them on modern computers, because their physics depends on FPS). Another benefit is that you can use integration logic to interpolate additional frames between physics simulation steps, resulting in smoother animations.
source to share
The fixed time step should really only be used in mathematical or scientific applications. What for? Because in a game, if you are running at 30fps, you will have a delta time of about 34ms, which means it took 34ms to update the previous frame and be ready to update the next one. Therefore, a fixed time step is not useful in most applications.
When it comes to physics engines, it almost always depends entirely on your game, but most of the time the physics engine runs on a separate thread, but it will still have to take delta time as a parameter to resolve collisions properly.
Delta time is the time it takes to complete the last frame.
Hope this helps.