Basic Delta Timing Explained

I know that there are lots of threads about Delta Timing on these forums but could someone explain in the most basic terms how to implement it as the examples I have seen all appear quite complex.

I remember a decent tutorial on Blitz Coder about the subject but sadly I can no longer find this. Has anybody got the link?

Any help would be most welcome.

Jason.

here ya go...

http://home.cmit.net/rwolbeck/programmingtutorial/

Most basic terms may be:

Imagine when there are many frames per second, the player has to be moved only small steps every frame to move a given distance in a given time. If there are only a few frames per second then the steps have to be relative big to walk the same distance in the same time. So basicly you take the framerate and use it as a divider for all movements and animation commands. (you can use Animate with static values, the delta correction is applied with the updateworld call:)

ms=millisecs()-17

while game
...
; calculating delta stuff
old_ms = ms
ms=millisecs()
frametime=ms-old_ms
speed_factor#=float(frametime)/16.667

...

moveentity player,0,0,playerspeed# * speed_factor#
...

UpdateWorld(speed_factor#)
...
wend

this line:
speed_factor#=float(frametime)/16.667
means, if the game is running with 60Hz then the delta factor will be 1.0 (1000 / 16.667 = 60). If there are less frames then it will be higher.
You should also prepare the initialization of old_ms before you enter the main loop: ms=millisecs()-17.

Then maybe fancy framerates should be handled by some exceptional reactions. Some people also like to smooth the frametime over a few frames.

As you probably know, animation is achieved by moving objects small amounts each frame, which then blend together into what appears to be smooth motion.

If you call "MoveEntity player, 0, 0, .1" every frame, then you're moving your player at a rate of .1 units per frame.

What many beginners fail to consider is that frames do not always progress consistently. Depending on the power of your computer, and the complexity of what's currently being displayed, and what's running in your computer's background, the frame time may change. Consequently, this means that the speed of your game objects will also change if you don't take this into account.

Correcting for the inconsistent frame times is really very simple. Using a simple formula, you can convert your inconsistent units-per-frame movement into units-per-second movement, which really makes a lot more sense. The easiest way to do this is usually to make a simple function library:

Global lastTime
Global timeScale#

Function UpdateSpeeds()
  'Calculate the time ellapsed since last frame
  currentTime = MilliSecs()
  deltaTime = currentTime - lastTime
  lastTime = currentTime

  'And calculate a scale value to convert -per-second values to -per-frame values
  timeScale = deltaTime / 1000.0
End Function

Function Eq#(unitsPerSecond#)
  'Convert the given units-per-second value to units-per-frame
  Return unitsPerSecond * timeScale
End Function

Simply call UpdateSpeeds() every loop and use Eq() to calculate the speeds used in the program.

The way it works is simple: Instead of moving the object a constant amount each frame, it moves it based on the amount of time the frame takes to complete. So if you're running at 100 frames-per-second, and you want your object to move at 1 unit-per-second, the object should move 1/100th of a unit each frame. If the frame rate jumps down to 30 FPS, to maintain the same real-world speed, the Eq() function will automatically adapt and start moving the object at 1/30th of a unit per frame.

So the same principles apply to both 2D and 3D? Thanks for the explanations guys, it has certainly helped. I`m going to go and give it a try.

BTW does delta time only apply to movement or does animation, as in changing the frame of a character for example, also need to be taken into account? How would that be done.

Jason.

I have already explained that, Using the delta value in UpdateWorld() will delta-correct all animated meshes automaticly. For 2D you have to consider pixels, they may prevent you from smoothly moving things.

Yes, and also 1D and 4D and 5D etc. Any sort of time based "movement" can be frame-rate-equalized - it doesn't even need to have anything to do with dimensional space. For example, you could reduce the amount of fuel of a vehicle at a controlled rate this way.


I'm not sure, but I think Blitz3D does this automatically. When you call UpdateWorld, I think you can supply it a delta-time parameter which it uses to keep animations running at a constant speed. But if you increment your character's frames manually, you may have to equalize this.

Thank you for this tipp it fits right in the tiberion game iam writing now :=)


UpdateWorld [anim_speed#]

Parameters:


anim_speed# (optional) - a master control for animation speed. Defaults to 1.