# random spike in delta time

The title pretty much sums it up. I'm using delta time to move my objects and every few seconds the delta time will spike and all the objects will jump forward. Should I just Interpolate the delta time to eliminate spikes, I don't want to do this because it could cause other problems but it could be a solution

-
Have you attempted to determine the cause of the spike in delta time? It seems like a performance problem, but you are asking about making your game avoid the symptom rather then treat it. – Seth Battin Oct 27 '12 at 5:44
You might want to clarify your question a bit. If you want help on the cause the spike, provide a bit more info. Mentioning specific technologies may lead to better discussions. For example, if you use a language with a garbage collector it may be that the collector kicks in "randomly". There are a few strategies to remedy this particular situation. – Willem Oct 27 '12 at 6:21
Always use a virtual, non wall clock, time because your delta real-time can always spike, that's beyond your control since a lot of different programs are running while your game runs. – Roy T. Oct 27 '12 at 11:26
Did you profile? What exactly happens in the frames with spikes? – Maik Semder Oct 27 '12 at 12:12

It might help if you'd post a simple code example demonstrating the problem, but I'm going to take a wild guess and suggest that your time resolution is too low.

In particular, consider what happens if your simulation loop takes, say, 0.02 seconds to run, but your timer only counts whole seconds. So, for 49 out of 50 loops, the delta time you'll calculate will be exactly zero, and so the simulation time will not advance — but then the timer ticks over, the delta time becomes 1 second, and the simulation loop suddenly goes "Oh, wow, that last iteration sure took a long time! I'll have to use a huge time step to catch up!"

The best solution is simply to use a more precise time source. However, if you really can't get the time resolution you want (or if something else is causing unavoidable jitter in your loop timings), you can stabilize the timing prediction by averaging the delta time over several iterations, i.e. instead of doing this:

```var baseTime = getCurrentTime();
while ( running ) {
var currentTime = getCurrentTime();
var deltaTime = currentTime - baseTime;
baseTime = currentTime;
simulate( deltaTime );
}
```

you could do e.g. this:

```var baseTime = getCurrentTime();
var timeQueue = new Queue ();
while ( running ) {
var currentTime = getCurrentTime();
timeQueue.push( getCurrentTime() );
if ( timeQueue.length > 10 ) {
baseTime = timeQueue.shift();
}
var deltaTime = (currentTime - baseTime) / timeQueue.length;
simulate( deltaTime );
}
```
-
I didn't think a code sample was needed because it seemed to be a pretty general problem. I'm using glfw's glfwGetTime which is supposed to have up to 1 nanosecond of precision. I didn't think more precision was necessarily. – malco Oct 27 '12 at 3:02
OK, obvious question: `glfwGetTime()` returns a double -- are you sure your time variables are doubles and not ints? – Ilmari Karonen Oct 27 '12 at 3:10