Quote: "1. The value is essentially "milliseconds per frame." I edited the post above to use a realistic value. Sorry I missed that the first time. :/
deltaTime# = (worldTime - oldTime) * (1000 / 60.0)"
This is not correct.
Should Be: deltaTime# =
ABS(worldTime - oldTime)
/ (1000 / 60.0)
Simplfied To: deltaTime# =
ABS(worldTime - oldTime)
/ (16.6666)
Your code doesn't work and will completely fail when the timer reaches too high. The timer becomes negative and starts counting backwards. It also doesn't relate everything to 60fps as was intended as the math is wrong. Technically, you can remove all of the division and multiplication and just use the ABS() difference.
Quote: "1. zeroSlave actually used the wrong formula for Timer-based movement. A good discussion about timer-based movement can be found here."
This is a good and simple discussion. Excellent Example.
Quote: "On the other spectrum, there can be issues when screen fps is above 200 on newer processors/GPUs where the factor can be so miniscule that movement using the factor can seem to be faster than it should be. This can be easily fixed by restricting the frame rate to be no higher than your target frame rate or just above it (target frame rate would be ~60, maximum would be ~80)."
This is an excellent point to make. This also relates to lag spikes. If the game suddenly slows or stops briefly, you don't want those movement increments to turn into people teleporting through walls, etc. A frame limiter is good for the high end, a "factor" limiter is also good for the low, set a minimum frame rate.
If ABS(worldTime - oldTime) > 1000 Then deltaTime# = 0.0
This is really important and almost everyone seems to skip this. If you are in a menu, paused, holding down a key-press or whatever, and the timer code isn't used for a long period like seconds or more... When the game-play returns there's going to be a huge super jump everywhere. Building a delta / factor limiter means you don't have to remember to put timer reset code everywhere.
Quote: "
1. Why you divide the elapsed time ( in milliseconds ) with the float value of 60.0 ? What is the concept behind it ?
2. What happens when deltaTime# is multiplied with the angle value of the command "turn object left" ?
3. Do I have to apply the deltaTime# to each and every functions of Dark Basic Pro including the plugin commands found in EZRotate ?
4. Is this a full proof method ? Has this method worked on diverse processor power without any glitch ? "
1. The mentality (there are others) is that you can write the code as units per frame at 60 frames per second. Move 12 * factor? Would move 12 units at the classic PC Game ideal frame rate of 60. If the frame rate is too fast or too slow the 12 is scaled to make on screen movement appear the proper speed. The 60 should actually be 1000/60 and this whole part is not necessary, but it can help visualize movement when reading the code.
2. If on each frame you are turning a certain number of degrees, that rotation is going to slow or speed up with frame rate. So the amount of each rotation is scaled on each frame to cancel out speed changes from the frame rate.
3. Anything that is affected by frame rate changes. Movement and rotation both decrease when frame rate goes down because they happen less often. So individual movements need to go get bigger to compensate, so you cover the same distance in the same amount of time.
However what nobody mentions is that random events are opposite. Random events need to get less likely when frame rate goes up, and more likely when frame rate goes down.
4. This method is enough for pretty much any game. You can get more precise timers with plugins. The vast majority of the time the built in timer is fine.
Quote: " I don't really think it's foolproof. You'd have to take in the consideration that person may never turn their computer off, so the value return from timer() would be too large to be usable. I haven't encountered this, but I would assume it's a possibility."
This is not true, with correct code. The Timer() loops back to 0. There is a glitch with DBP and at a certain point the timer suddenly turns into a negative number counting backwards. But
ABS() solves this completely. It is full proof, unless you need timing precision higher than a typical video game.
Here is a fixed example:
sync on
sync rate 0
make object cube 1, 1
autocam off
do
deltaTime# = ABS(Timer() - oldTime) / 16.666
If ABS(Timer() - oldTime) > 1000 Then deltaTime# = 0.0
oldTime = Timer()
turn object left 1, 1 * deltaTime#
sync
loop
end
The example is unrealistic for anything but the simplest of games and using Functions is more flexible. Better to do this:
sync on
sync rate 0
Global deltaTime#
Global oldTime
make object cube 1, 1
autocam off
do
TBM_Update()
turn object left 1, 1 * deltaTime#
sync
loop
end
Function TBM_Update()
deltaTime# = ABS(Timer() - oldTime) / 16.666
If ABS(Timer() - oldTime) > 1000 Then deltaTime# = 0.0
oldTime = Timer()
EndFunction
