I started developing games recently, teaching myself using a german book about C++ and Direct3D 9.

The author states, player movement should be implemented using a time delta, like this

player.position.x += time.delta * movementFactor

as opposed to an implementation without incorporating the time passed since last frame; i.e like this

player.position.x += movementFactor

Latter solution would cause other players to move faster, since the expression above would be executed more often on faster CPUs. (More explanation on Tayacan's answer below)

Is there any other solution to this problem?

Old, poorly phrased question I wrote when I was young:

I'm reading on a Book that's about Gamedevelopment with C++ and DirectX 9.

There is something that interrests me: It says that playermovements are increasing with the power of the CPU. Becouse a faster CPU will move the player with every frame ( better CPU = better FPS ) To bypass it, it says you have just to multiplicate time*movementfactor .

I'd like to know is there an another way to bypass it ?

  • \$\begingroup\$ Do you mean player movement alone, or whole logic? You can fix your FPS (limit it so some max value) \$\endgroup\$ Nov 6, 2012 at 21:50
  • \$\begingroup\$ It is an old question, but just want to mention based on Markus comment that limiting FPS with max value won't fix this. You will still have a difference if FPS drop for a player, it will move slower. A good solution is to use the delta time. \$\endgroup\$
    – ElJackiste
    Nov 12, 2021 at 11:48

2 Answers 2


Why do you want another way? The one you describe is what you'd use in any kind of game development, whether or not you use DirectX.

The problem is this: In (most) games you have a main loop. This loop runs as fast as the hardware allows. However, people use different hardware, so on some computers, this will be faster than on others. So in order to make an object in a game move with the same speed on any hardware, you multiply the movement vector with the time, in seconds, since last time the loop was run. This also has the benefit that if you're moving the object, say, 5 * time units in some direction, that's the same as saying "move it 5 units/seconds".

  • \$\begingroup\$ I don't want another way, I just asked if there is another (alternative )way to bypass it. But still helpfull :) Thank you \$\endgroup\$
    – LaVolpe
    Nov 6, 2012 at 19:23
  • 2
    \$\begingroup\$ There really is no alternative, the update method is called whenever possible and at no specific time interval. As a result scaling is the only possible way to manage the velocity of game objects. You could just do a +1 every frame if you want, but don't count on getting consistent performance across machines or even on your own (especially if you have another program open). \$\endgroup\$ Nov 6, 2012 at 19:43
  • \$\begingroup\$ This answer and the comment above seem to gloss over the use of Fixed Timestep game loops, popular for fairness and consistency in multiplayer games especially. \$\endgroup\$
    – DMGregory
    Dec 12, 2017 at 8:04

If you need another way, there is an another way, as mentioned by DMGregory too. In main loop where an update is called after every frame, you can make your fixed update function which should be called after every fixed interval of time. Many games (I think all multiplayer games) uses this concept. As it's called after a fixed interval so you don't have to worry about time.delta and just make your movement factor according to that fixed time interval and you are good to go.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .