3 ms·

It's for physics. Writing a [stable] fixed time step simulation is significantly simpler than variable time step. Tons of games do it (console ports are guilty

It's for physics. Writing a [stable] fixed time step simulation is significantly simpler than variable time step. Tons of games do it (console ports are guilty of fixed 30FPS), and it really sucks.

derefr 4y ago
In most cases there's no reason to couple physics to graphics. The game "is" the physics engine (esp. in cases of networked games); while the graphics engine is simply an "observer" of the output of the physics engine, trying to interpolate/extrapolate graphics frames given a stream of physics frames. Do physics at 30FPS in one thread; draw graphics as fast as you can in a separate thread; and at the beginning of each render frame, get the latest physics integration-state, and how much time it's been since it was calculated, and extrapolate object displacements+rotations (incl. the camera) linearly from existing velocities. Those changes will be so small, and corrected by the next physics-step so soon, that it'll almost always look correct. The only reason to not do this, is if you can't afford concurrent execution (i.e. you only have a single CPU core and interrupts are expensive), and you also don't have a practical Lowest Common Multiple frequency to run an event-loop at. Which is something that was maybe true in the gameboy era, but hasn't been true for at least 30 years.
- danhau 4y ago
  > Do physics at 30FPS in one thread; draw graphics as fast as you can in a separate thread This sounds like a race condition nightmare. How would one guarantee synchronization? One big mutex for the entire physics state? Or don‘t bother and read whatever values you get in the render thread? I suppose a single threaded context you would automatically get something like a global mutex, just without the mutex, thanks to the leap frogging nature (frame, frame, frame, tick, frame, frame, frame, tick, …). At least with a fixed timestep.
  - heavenlyblue 4y ago
    Just have 2 snapshots of all of the positions of all elements in the game (which is trivial in terms of storage requirements), just the same way you have it with double-buffering for the pixels on the screen.

It's for physics. Writing a [stable] fixed time step simulation is significantly simpler than variable time step. Tons of games do it (console ports are guilty of fixed 30FPS), and it really sucks.

derefr 4y ago

In most cases there's no reason to couple physics to graphics. The game "is" the physics engine (esp. in cases of networked games); while the graphics engine is simply an "observer" of the output of the physics engine, trying to interpolate/extrapolate graphics frames given a stream of physics frames. Do physics at 30FPS in one thread; draw graphics as fast as you can in a separate thread; and at the beginning of each render frame, get the latest physics integration-state, and how much time it's been since it was calculated, and extrapolate object displacements+rotations (incl. the camera) linearly from existing velocities. Those changes will be so small, and corrected by the next physics-step so soon, that it'll almost always look correct. The only reason to not do this, is if you can't afford concurrent execution (i.e. you only have a single CPU core and interrupts are expensive), and you also don't have a practical Lowest Common Multiple frequency to run an event-loop at. Which is something that was maybe true in the gameboy era, but hasn't been true for at least 30 years.

danhau 4y ago
> Do physics at 30FPS in one thread; draw graphics as fast as you can in a separate thread This sounds like a race condition nightmare. How would one guarantee synchronization? One big mutex for the entire physics state? Or don‘t bother and read whatever values you get in the render thread? I suppose a single threaded context you would automatically get something like a global mutex, just without the mutex, thanks to the leap frogging nature (frame, frame, frame, tick, frame, frame, frame, tick, …). At least with a fixed timestep.
- heavenlyblue 4y ago
  Just have 2 snapshots of all of the positions of all elements in the game (which is trivial in terms of storage requirements), just the same way you have it with double-buffering for the pixels on the screen.