Timer Based Movement - Correcting For Changing Frame Rate.
`Setup TBM Variables
Global tbm_multiplier#
Global tbm_lastTime
Global tbm_bulletTime#
tbm_bulletTime# = 1.0
Rem Updates timer based correction multiplier.
Rem Sets multiplier to 0 if too much time passed for safety.
Rem tbm_bulletTime# will control bullet time slow motion effects.
Function TBM_Update()
`Get the time since last timing update
diff# = (Timer() - tbm_lastTime)
`Calculate a new speed correction multiplier
tbm_multiplier# = diff# * tbm_bulletTime#
`If too much time passes abort and make the multiplier 0.
If diff# > 1000.0 then tbm_multiplier = 0.0
`record the update time
tbm_lastTime = Timer()
EndFunction
The general idea is that with higher frame rate movement happens more often, and with lower frame rate movement happens less often. Therefore you need to make each movement bigger or smaller to keep object moving at the same speed.
This is done by creating a 'multiplier' that you scale individual movement jumps with.
This also applies to ANYTHING else that is affected by frame rate. Animation speed is an example.
Random Triggered Events require division not multiplication. If you have a 1 in 1000 chance of a bomb exploding each game loop, it should become less likely with higher frame rate. So divide the multiplier instead, and protect against division by zero. Only on events triggers that are affected by frame rate, and not for example based on input.
Don't Forget Safety Limits.
If a player pauses the game for 4 straight days, you don't want him teleporting into Jupiter orbit when he unpauses the game. So if more than a second is passing in your game loop, set the multiplier to zero. Nothing will move on that loop, and on the next loop the timing will normalize.
Avoid Frame Rate Smoothing.
There are a number of fantastic and brilliant people on the forum that like to smooth timing calculations over 30 frames. Avoid doing this. This is a horrible bad habit. Professional studios don't do this. If you have jitters, lag spikes, choppiness then this is painting over the problem. This is creating an effect that slows/speeds the game to try to hide the lag, instead of addressing the source of the lag and being efficient. This usually looks good to people designing the game, who can cap the frame rate, and stay at the cap, and ignore what actual player experience will be like. If your frame rate is erratic, your TBM code literally spits out the wrong answers every time. If your game is networked, then player speed will be all weird since their games are running at different speeds with little consistency. So do the grunt work and fix the lag problems directly.
