Speed, delta time and movement

Question

player.vx = scroll_speed * dt

/* Update positions */
player.x += player.vx
player.y += player.vy

I have a delta time in miliseconds, and I was wondering how I can use it properly. I tried the above, but that makes the player go fast when the computer is fast, and the player go slow when the computer is slow. The same thing happens with jumping. The player can jump really high when the computer is faster.

This is sort of unfair, I think, because.

Should I be doing this someway else? Thanks.

Answer 1

Velocity is given in [distance units] per second, and you have a delta time in seconds (or at least you should, for all the reasons specified by Yakyb in his answer). The velocity tells you how far you want to travel in a second, so if your delta time from the previous frame is (for example) 0.1 seconds, and your velocity is 50 pixels/second, then the player should move 50 * 0.1 = 5 pixels in the new frame.

So, the simplest case would be to set your velocity to a constant value (e.g. 50), and either apply it or not based on whether the player is pushing the appropriate movement key / button / whatever:

vxMax = 50
if ([is the "move right" button down?])
{
    player.vx = vxMax
}
else
{
    player.vx = 0
}
player.x += player.vx * dt

// Ditto for player.vy and player.y

This is a good start, but it has some problems. First, movement is will be jerky -- the player will start and stop moving instantly, and always move at a constant velocity. You probably want to gradually increase the velocity from 0 up to the maximum velocity over several frames while the movement key is held, and then gradually decelerate to back to velocity=0 when the key is released.

This approach will also break down when the delta time is very large. For example, if you hit a sudden unrelated system performance hitch that causes one frame to take ten seconds to render, then your delta time will be (relatively) huge. Unless your collision detection code is very careful, this will cause the player to jump instantly across the game world, passing through any walls and obstacles in between. There are ways to avoid this; you can detect abnormally large time steps and break them down internally into several smaller time steps, checking for collisions every step of the way. Or you can look into continuous collision detection, swept-volume collision detection...but that's way beyond the scope of this question.

Answer 2

dt shouldn't be in milliseconds

if your speed is how much you move per second, you dt should be representative of seconds

i.e. if you are running at 60fps it should take you 60 frame cycles to move one unit of your velocity.

therefore your dt should be

(time since last frame in milliseconds) / 1000

or simply how much as a percentage of one second has the game moved on since the last frame

in the example of 60fps

16.6666 / 1000

Answer 3

This is a bit more complicated.

Basically, you want to keep a variable that every frame accumulates the time it takes the game to render, and when it comes to game logic (especially physics), divide it into fixed discrete chunks and interpolate the renderable state based on the remainder.

This is a canonical article describing this technique along with several other approaches for managing delta time in game loops, you really, really should read this:

http://gafferongames.com/game-physics/fix-your-timestep/