I was urged to post my solution for bullet time.

In my engine there are 2 timer modifiers. There is only one timer as far as the game loop is concerned, but there are 2 places where you can modify the amount of time that passes.
First the engine updates how much time has passed. This update goes through the first scaling modifier, and it ultimately tricks all engine sub-systems into believing the game is faster or slower than it really is.
This is the value the game engine uses to perform logical updates, which are at a fixed rate. A macro lets you define this rate but many games tend towards 0.032 seconds, many others using 0.033333333 seconds.

When performing a logical update, the game’s “scene” is, well, logically updated. There can be multiple scenes but generally there is only one.
It contains every object in the scene. All the characters, the ground, the cameras, the particles, etc.

Each scene has its own secondary speed multiplier. The time passed down to the scene is again scaled, and this is the value used to update all of the objects in the scene. Physics are still run each time the scene is updated, but the amount of time passing is scaled down.

All time accumulators are in 64-bit integer microseconds for all the precision would could need, and deltas between frames are stores as seconds, in floating-point format.


The example I mentioned before about speed up the game uses the first time modifier.
You could use one modifier such that, if the value is above 1.0, the original time value is modified, and if it is less than 1.0 then the second (scene) time value is modified, however this would remove the possibility of scenes running at different speeds, which is valuable.

Basically, the physics are still run 30 times per second, but with a much smaller rate of advancement. I decoupled the scene time from the engine time for this very purpose, and it allows you to move the camera at a reasonable rate through the world because the programmer’s state class, which is responsible for providing a virtual function that handles logical ticks (and one for render updates) is responsible for passing the game class (which has the time needed by the scene, among other things) off to the scene to let the scene do all of the updating.
The programmer doesn’t have to scale any time values, just set the time scale for each scene it wants to run and be done with it.
But the programmer has access to the original game engine’s timer, and can move the camera by “real time” while the simulation runs in super-slow motion. Or it can use the scene’s scaled time values and keep the camera in slow-motion too (this would be implicit if the scene is running a cinematic and thus has control over the camera, or if the camera is attached to an object).



This solves all but one problem: slowing time gradually.
The core of this problem is that the previous time step’s length was not the same as the current time step’s length, which is basically a problem that variable-length simulations have all the time, not just in certain special-case situations.
And since this case is a controlled case, it is likely that there would be few if any noticeable simulation errors, and it would still have the benefit of being able to re-run the same simulation the same way every time, important for network play, etc.

Solving this in a completely stable way is unlikely, though replacing reaction forces with a series of impulses (micro-collisions) would probably eliminate all of the artifacts you would encounter in such a controlled situation. This adds stability to any simulation, not just fixed-stepped ones, but this is only adding to stability, not ensuring it 100%. Results may vary on variable time steps.

The benefit here, again, is that the simulation repeats exactly the same way every time.
If it works once in the developers’ shops, it will work for every player out there the same way every time.
That is just not something you can ever guarantee with variable time-stepping, and that frightens developers. Why wouldn’t it?
People have hardware of all shapes and sizes, and even on consoles there is the possibility of too many explosions leading to frame-rate drops.
Fixed-stepping is the only option that reassures developers that they won’t have simulation explosions or inconsistent or undesired results on every player’s screen playing the game.


L. Spiro

Physics are still run each time the scene is updated, but the amount of time passing is scaled down.

[...]

Basically, the physics are still run 30 times per second, but with a much smaller rate of advancement.

I may be missing something, but isn't that variable time stepping? Yes, you're updating at a constant rate (30 times per second), but the time step is variable, isn't it?

[quote name='Cornstalks' timestamp='1336152882' post='4937427']
I may be missing something, but isn't that variable time stepping? Yes, you're updating at a constant rate (30 times per second), but the time step is variable, isn't it?

L. Spiro says "

[background=rgb(250, 251, 252)]slowing time gradually" - so is presumably hoping that a gradual transition from a normal timestep to a smaller one won't generate any noticeable artefacts.[/background]

[/quote]
I know, but I'm trying to connect L. Spiro's previous statements about fixed time stepping with what sounds like (to me) variable time stepping. Even if you slow it gradually, it's still variable time stepping instead of fixed time stepping.

I may be missing something, but isn't that variable time stepping? Yes, you're updating at a constant rate (30 times per second), but the time step is variable, isn't it?

Yes, but mostly no.
Variable means it changes, so by definition it is indeed variable.
But no.
It changed because you the game programmer decided not only that it should change but also by how much.
Variable time steps, by definition, are under no control. This makes them volatile and useless for real production.
No control. They could lag behind due to file access or any other reason MrRowl made it clear could happen at any time.

Literally, fixed time steps mean, of course, that the steps never changed.
In reality, which doesn’t give a damn about literal interpretations of words, “fixed” simply means “within our control”.

L. Spiro says "

[background=rgb(250, 251, 252)]slowing time gradually" - so is presumably hoping that a gradual transition from a normal timestep to a smaller one won't generate any noticeable artefacts. It's definitely more likely to be well behaved than a sudden jump... but if the game requires an immediate change in physics time rate, you've still got to make sure the physics engine doesn't do nasty things when the timestep changes.[/background]

Hi, I am L. Spiro and I don’t explain all the high points of my view without explaining the low points. Err no?
Did I not clearly explain that all physics simulations, fixed or not, have a problem with variable time steps? Do you plan to make a case based on that fact that fixed time steps have to resolve problems fewer than 0.1 times as often as variable steps?

Since you were the one who, via PM, urged me to post my solution to bullet time, which is extremely viable, I find it hard to believe you are still trying to wrestle this issue and win the debate.


L. Spiro

[quote name='Cornstalks' timestamp='1336152882' post='4937427']
I may be missing something, but isn't that variable time stepping? Yes, you're updating at a constant rate (30 times per second), but the time step is variable, isn't it?

Yes, but mostly no.
Variable means it changes, so by definition it is indeed variable.
But no.
It changed because you the game programmer decided not only that it should change but also by how much.
Variable time steps, by definition, are under no control. This makes them volatile and useless for real production.
No control. They could lag behind due to file access or any other reason MrRowl made it clear could happen at any time.

Literally, fixed time steps mean, of course, that the steps never changed.
In reality, which doesn’t give a damn about literal interpretations of words, “fixed” simply means “within our control”.
[/quote]
Ah, I see. I understand what you were saying now. Thanks.