# How to get and use delta time

I have mice looking and walking in my game, but they are very slow and hard to use. I think it's because I'm using fixed speed. I heard that in big projects developers use delta time. How do I calculate delta time in glut? How do I calculate speed using delta time?

The "delta time" used to be the time elapsed between two frame updates (but it can also be used in other contexts; this is usually the result of a time subtraction).

You can get the delta time in glut using the glutGet method and the GLUT_ELAPSED_TIME parameter, plus some operations.

The following line returns the number of milliseconds since glutInit was called (or first call to glutGet(GLUT_ELAPSED_TIME)) :

int timeSinceStart = glutGet(GLUT_ELAPSED_TIME);


So if you register the current timeSinceStart at each rendering loop, you can know the deltaTime by subtracting the old one to the new one.

int oldTimeSinceStart = 0;

while( ... )
{
int timeSinceStart = glutGet(GLUT_ELAPSED_TIME);
int deltaTime = timeSinceStart - oldTimeSinceStart;
oldTimeSinceStart = timeSinceStart;

//... stuff to update using deltaTime
}


You can also do it almost the same way, using the C/C++ ctime library with clock() and the macro constant expression CLOCKS_PER_SEC that specifies the relation between a clock tick and a second.

Basically, you can use deltaTime to update your movements in ratio to this elapsed time instead of using a fixed time value. This way, the movement speed of your character should be almost the same if your program runs at 60 fps or if it runs at 10 fps.

Here is a small example: suppose you want to move something by 10 units each second on the x axis. You could do something like this (if deltaTime use milliseconds indeed).

Position.x += 10/1000 * deltaTime;


This way, whether your program updated 2 times or 100 times, 1 second later the position should be almost the same, and the game-play is less impacted by the low fps of a small computer than if it use fixed values.

• With fixed values ==> low fps = less updates = slow movements whereas high fps = more updates = very fast movements.

• With deltaTime ==> "almost" the same movements.

Finally, you should read Fixed time step vs Variable time step on gamedev.stackexchange.

• It returns milliseconds as an integer? Gross, and possibly not sufficient. I've always had to use platform-specific timers and then just avoided GLUT like the plague since it's super not great for games. – Sean Middleditch Jul 17 '13 at 20:32
• @Sean I don't use GLUT either, but that was in the parameter of the question so I answered with this in mind ;) However, I'm intrigued by your position in regards the "insufficiency" of int to handle milliseconds in games. A positive int usually go up to 2.147.483.647 if signed and up to 4.294.967.295 if unsigned... so even if we consider the smaller one, 2.147.483.647 milliseconds is almost 25 days... It should be quite enough to handle most game timers and even if it's not enough we can still reasonably use unsigned int (~50 days) or even a long long (as I usually do). – Valkea Jul 17 '13 at 21:20
• @Valkea The point isn't the max, it's the resolution at the low end. Since a single frame at 60 FPS is just 16 2/3rds ms, an accuracy of 1ms (from representing milliseconds as integers) represents an error margin of more than 5% - more than enough to throw simulations far out of whack. An integer count of microseconds would be bearable, but milliseconds are just too coarse. – Steven Stadnicki Jul 18 '13 at 0:14
• Yeah, you need sub-millisecond timing for many things and a high-resolution timer to find that, which GLUT does not provide (that I know of). It's not bad to just write a little platform code to use QueryPerformanceCounter on Windows and gettimeofday on most others. You're going to have to get your hands dirty and aim for a bit more than the least common denominator of platform APIs, especially in C and C++. – Sean Middleditch Jul 18 '13 at 0:48
• Such a precision is not useful for all games. However this is a very interesting explanation that fully answers my interrogation about your point of view concerning int and clocks. I never needed high precision clock yet, but I guess it's time to deepen my knowledge of the matter. Thank you ;) – Valkea Jul 18 '13 at 1:59