Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm currently putting together my game loop based on the "Fix Your Timestep" article at gafferongames.com. This is going fine, but I'm also trying to implement a 'time scale', i.e. a way to control the game speed.

Currently, the delta time is added to an accumulator, and then a loop iterates the physics as many times as there are multiples of the fixed time step in the accumulator.

Now, if I want to add a time scale, I should multiply the delta time by some factor, 0.5 for half speed or something, yes?

Here are my questions:

Should I still use the real fixed time step (prior to multiplication) to determine how often the physics is iterated, but perform the actual calculations with the increased or decreased time step? Or should I use the new time step for both, but surely this would just result in the same behaviour but with higher resolution calculations?

Wait, wait, wait. I have to affect the accumulator too, right? Then it would increase by a smaller frame time, but it would do the right amount of iterations with smaller dTs, over the right amount of time (the real delta time). That'd do it, right?

Given that the purpose of the fixed time step is to perform stable physics calculations, how can I combine these two concepts without jeopardising that stability?

Is it simply that LARGE time steps cause instability? Can I therefore slow down as much as I like? Or is it the variations in time step that causes instability?

Thanks

share|improve this question
2  
A minor remark: contrary to your statements, fixed time-steps are often not really a stability requirement (they don't guarantee it either!). They are, however, necessary for a deterministic engine. A physics sim can run with variable Dt, provided it does not exceed the stability interval of its integrator. One problem with your time scaling idea is that, when using fixed dt iterations, if the fixed step becomes larger than the scaled dt, you're gonna get jerky physics.. conversely, too many fixed iterations can alter fluidity as well. –  teodron Jul 27 '13 at 14:34
    
@teodron That's interesting about fixed steps and stability. Regarding the problem, the time step supplied to the physics would be scaled as well as the actual delta time, so they would remain in proportion, I think. I think I've answered my first question myself. The answer to my second is that a variable physics timestep is acceptable within a certain tolerance, given by the stability interval of the integrator used? –  Scott Oliver Jul 27 '13 at 14:47
    
If no one has any criticism of the above, I'll supply an answer. :) –  Scott Oliver Jul 27 '13 at 15:15
    
Well, if you also need determinism, it's not quite ok to scale both the quantized/fixed Dt. If you don't need determinism and you aim to achieve "bullet time" effects, scaling that fixed Dt by a subunitary factor is quite ok (won't harm stability). But if you scale the fixed Dt increasing it, you may get outside the "safe" range of your integrator (e.g. explicit vs implicit Euler integrators are quite different in this respect, the latter being more stable when the fixed Dt, which it uses, is pretty high). Before posting the answer, test it for your particular case :). Have fun coding! –  teodron Jul 27 '13 at 17:19
add comment

1 Answer

up vote 2 down vote accepted

Regarding the first question, I believe that using the altered delta time to increase the accumulator, and the altered fixed step to decrease it, should keep everything working correctly. In reality, I only need to add the time scale behind the scenes, and the type of game loop specified in Fix Your Timestep should still work.

According to @teodron, the answer to my second is that a variable physics timestep is acceptable within a certain tolerance, given by the stability interval of the integrator used. In other words, I should be able to apply the time scale safely, within reason.

I'm going to implement this and test. If there is anything incorrect about what I said above, I'll edit to reflect that.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.