Message from the Editor
Time for another issue of BASIC Gaming!
Life has been really hectic for me lately and I'm basically running on fumes. For the past two months I had so little free time and I’m still struggling to juggle several projects within that limited amount of time. Luckily, I managed to complete this issue of BASIC Gaming (my number one project on the list) during the past weekend and today, as it was due time for a new release. The other reason is that my FBGD competition is finishing soon, so I'll need time to dedicate to that in the next few weeks. Not to mention some other plans I have that now, with this issue released, have a chance to come to life. All in all, I didn't want to procrastinate with this issue as God knows what awaits me the next few weeks professionally. I sincerely hope this period of madness at work won't continue indefinitely and that I'll be able to return to the community in my usual productive form. This community and hobby I find quite rewarding at this point of my life and I don’t want to lose the positive momentum.
Once more, thanks to all developers for developing and allowing me to have something to write about. Let's keep our realistically small and underground community going, because despite that, we know that we are special and will remain that. Others might not understand, but we know we are among the chosen few. We will all cherish our memories of this awesome place and the time we had in it in the winter of our lives. I guarantee you that. But until then, be great!
With love,
~ Lachie Dazdarian (lachie13@yahoo.com)
Proper timing of loops - Variable time step method
Written by Lachie Dazdarian (January, 2012)
This tutorial deals with proper timing of programs, namely loops in games.
The method I will be presenting is called variable time step method (aka time-based movement).
Beside this, in my opinion best method, there are several other options for controlling the speed of your programs: limiting the frame rate, vertical refresh and SLEEP command.
All of them have big disadvantages if used alone.
SLEEP is not reliable, varies on different OSes or imposes a minimum value.
Limiting the frame rate is problematic because you need to force a pause in your program every cycle until a preset time passes. The question is, what to put in the pause loop? SLEEP? But SLEEP has a minimum value in Windows XP for example (15 milliseconds), so high FPS rates are not an option.
The third option is VYSNC command which matches your monitors refresh rate/frequency with the applications frame rate. Problems? Monitors have different refresh rate setups. You can force a preset refresh rate through your program (I'm not sure if all end-users will like that), but even that doesn't work in all situations, because some video cards simply don't allow you to turn on/off vsync via your program. Sooner or later a user on whose PCs your application won't be able to turn on vsync will report that he/she can't play your game.
Solution? Variable time step method. In my opinion, the most reliable and what is the best, it is indiscriminatory. You can use it with vysnc, sleep, whatever. Because it will adjust to the frame rate of your program, no matter how you control this frame rate.
How it works? Basically, all the movement (and animation) in your game should be connected to the time elapsed between two loops in this manner:
object_position_x = object_position_x + object_speed_x * time_elapsed * arbitrary_factor
The higher the speed of your program, the more cycles run in one second, more times the formula above is applied, but the absolute movement remains the same because time_elapsed is lower.
The opposite situation, the lower the speed of your program, less number of cycles run in one second, less times the formula above is applied, but the absolute movement remains the same because time_elapsed is higher.
Let's see this applied in an example featuring both movement and animation. To enable variable time step method we will be using the following variables:
Dim Shared As Double loop_time = 1, this_time, tb_movement_factor = 1
loop_time will be used to flag the time passed between two loops. this_time will flag the current time on the start of the loop, later used to calculate loop_time in the next loop. tb_movement_factor is an arbitrary factor times time elapsed I used earlier. It's a dynamic global factor applied on all movement/animation/physics formulae in each loop, and equals loop_time times a factor of your choice. If multiplied with a base FPS value, when the game runs with that frame rate, tb_movement_factor equals (or is quite close to) 1. This means, if you designed you game for 60 FPS and want to switch to variable time step method, your tb_movement_factor must equal loop_time * 60 for your game to run with the same speed. In other words, how your game/program behaves on 60 FPS without variable time step method, it will also behave when this method applied with tb_movement_factor equalling loop_time * 60.
With this method applied our main loop will look like this:
Do
loop_time = timer - this_time ' calculate time between two loops
this_time = timer ' set the current loop time
tb_movement_factor = loop_time * 60 ' adjust movement factor to 60 FPS
' Draw stuff here
Loop Until Multikey(FB.SC_ESCAPE)
The following code will put this method in use in an illustrative example. We'll load 6 frames of Guybrush Threepwood, a character from Monkey Island games, and move him across the screen. We will apply the variable time step method on the animation and movement.
We'll need this gfx file.
We'll start by placing the usual header for fbgfx programs, setup a 640*480 screen, 32bit color depth:
#include "fbgfx.bi"
Using FB
const FALSE = 0
const TRUE = 1
SCREEN 18,32,2,0 ' Sets gfx screen
Dim Shared As Integer workpage
The following pointer will point to the graphics data and the code after it loads the sprites from the image file into a memory buffer:
DIM SHARED Frame(6) AS ANY PTR
BLOAD "frames.bmp", 0
FOR imagepos AS INTEGER = 1 TO 6
Frame(imagepos) = IMAGECREATE (105, 157)
GET (3+(imagepos-1)*104,0)-(103+(imagepos-1)*104,155), Frame(imagepos)
NEXT imagepos
Our main loop will now look like this:
Do
loop_time = timer - this_time
this_time = timer
tb_movement_factor = loop_time * 60
guyframe = guyframe + 0.09 * tb_movement_factor
if guyframe > 6.5 then guyframe = 0.51 ' loop the frames (6 frames)
guybrush_x = guybrush_x + 2 * tb_movement_factor ' movement formula
if guybrush_x > 660 then
guybrush_x = -120
end if
screenlock
screenset workpage, workpage xor 1
LINE (0,0)-(639,479), RGB(255,255,255), BF ' Color the background white
PUT (guybrush_x ,140), Frame(guyframe), PSET ' Paste the Guybrush sprite
workpage xor = 1
screenunlock
Loop Until Multikey(FB.SC_ESCAPE)
We need to declare guyframe and guybrush_x variables with DOUBLE precision. guybrush_x flags the x position of Guybrush, and guyframe the current frame of Guybrush. As you can see guyframe loops from 0.51 to 6.5. 0.51 converts to integer 1, and 6.51 to integer 7, so we need to reset back to 0.51 on 6.5 to seamlessly loop from frame 1 to 6.
Note how the guyframe increase factor is connected with tb_movement_factor. 0.09 is derived at with trial and error to sync with the speed of walking.
Same logic is used with guybrush_x, where it increases by the amount of 2 times tb_movement_factor. When Guybrush goes off screen he is reset back to the left side.
You can put a SLEEP command inside the loop with various values to test the speed of the program.
I expanded this program a bit with a FPS counter and walk by time measuring so you can test it on different frame rates and note how the walk by time is always the same. On my PC I was getting a deviation under 4 hundreds of a second between 60 and 1000 FPS in a 6 seconds time range.
The final version of the test program (FreeBASIC):
#include "fbgfx.bi"
Using FB
const FALSE = 0
const TRUE = 1
SCREEN 18,32,2,0 ' Sets gfx screen
DIM SHARED Frame(6) AS ANY PTR ' Pointer to the memory buffer holding the sprites
Dim Shared AS Integer workpage
Dim Shared AS Double guyframe = 1 ' frame will be used to flag the current frame of Guybrush
Dim Shared AS Double guybrush_x = -120 ' this variable will be used to flag the x position of Guybrush
Dim Shared As Double walk_by_time = 0, start_walk_time = 0 ' these two variables will be used to flag
' the pass-by time of Guybrush
Dim Shared As Double loop_time = 1, this_time, tb_movement_factor = 1 ' variables related to time-based movement
' loop_time -> time passed between two consecutive loops (current time - time in previous loop)
' this_time -> variable used to flag the start time of the previous loop
' tb_movement_factor -> a factor that multiplies with every movement/timing variable in the game
' if you want to sync-it with 60 FPS (make it equal 1 if the game runs 60 FPS), you multiply loop_time
' with 60
' FPS related variables
Dim As Integer frames_per_sec = 0
Dim As Integer fps = 0
Dim As Double start_time = 0
Dim As Double timer_elapsed
start_walk_time = timer ' Initial values of our timing variables
loop_time = timer-this_time
this_time = timer
' The code that loads our Guybrush Threepwood variables
BLOAD "frames.bmp", 0
FOR imagepos AS INTEGER = 1 TO 6
Frame(imagepos) = IMAGECREATE (105, 157)
GET (3+(imagepos-1)*104,0)-(103+(imagepos-1)*104,155), Frame(imagepos)
NEXT imagepos
Do
loop_time = timer - this_time ' calculate time between two loops
this_time = timer ' set the current loop time
tb_movement_factor = loop_time * 60 ' adjust movement factor to 60 FPS
' (if the program runs 60 FPS, tb_movement_factor will be 1)
guyframe = guyframe + 0.09 * tb_movement_factor ' frame rotation (note how the speed of rotation is
' multiplied with tb_movement_factor)
if guyframe > 6.5 then guyframe = 0.51 ' loop the frames (6 frames)
guybrush_x = guybrush_x + 2 * tb_movement_factor ' movement formula
if guybrush_x > 660 then
walk_by_time = timer - start_walk_time ' when Guybrush goes off screen
start_walk_time = timer ' calculate walk-by time, reset the timer,
guybrush_x = -120 ' set him back on the left side of the screen
end if
screenlock ' Lock our screen (nothing will be
' displayed until we unlock the screen).
screenset workpage, workpage xor 1 ' Swap work pages.
LINE (0,0)-(639,479), RGB(255,255,255), BF ' Color the background white
PUT (guybrush_x ,140), Frame(guyframe), PSET ' Paste the Guybrush sprite
' Print some variables on the screen.
LOCATE 1,1
PRINT "FPS:"; fps
PRINT "time-based factor:"; tb_movement_factor
PRINT "walk-by time:"; walk_by_time
PRINT "guyframe:"; guyframe
workpage xor = 1 ' Swap work pages.
screenunlock ' Unlock the page to display what has been drawn.
'SLEEP 10, 1 ' Rem/unrem to test different FPS
frames_per_sec += 1 ' count loops
timer_elapsed = (timer - start_time) ' calculate when one second passes
if timer_elapsed > 1 then
fps = frames_per_sec/timer_elapsed ' when one second passes calculate FPS
frames_per_sec = 0 ' reset loop counter
start_time = timer ' reset start time (for 1 second formula)
end if
Loop Until Multikey(FB.SC_ESCAPE)
QB64 version of the above code:
SCREEN _NEWIMAGE(640, 480, 32) ' Set screen, resolution 640*480, 32 bit
DIM SHARED guyframe AS DOUBLE ' frame will be used to flag the current frame of Guybrush
DIM SHARED guybrush_x AS DOUBLE ' this variable will be used to flag the x position of Guybrush
DIM SHARED walk_by_time AS DOUBLE, start_walk_time AS DOUBLE ' these two variables will be used to flag
' the pass-by time of Guybrush
DIM SHARED loop_time AS DOUBLE, this_time AS DOUBLE, tb_movement_factor AS DOUBLE ' variables related to time-based movement
' loop_time -> time passed between two consecutive loops (current time - time in previous loop)
' this_time -> variable used to flag the start time of the previous loop
' tb_movement_factor -> a factor that multiplies with every movement/timing variable in the game
' if you want to sync-it with 60 FPS (make it equal 1 if the game runs 60 FPS), you multiply loop_time
' with 60
' FPS related variables
DIM frames_per_sec AS INTEGER
DIM fps AS INTEGER
DIM start_time AS DOUBLE
DIM timer_elapsed AS DOUBLE
start_walk_time = TIMER ' Initial values of our timing variables
loop_time = TIMER - this_time
this_time = TIMER
guyframe = 1
guybrush_x = -120
' Load the Guybrush frames into a memory buffer
frames& = _LOADIMAGE("frames.bmp")
DO
loop_time = TIMER - this_time ' calculate time between two loops
this_time = TIMER ' set the current loop time
tb_movement_factor = loop_time * 60 ' adjust movement factor to 60 FPS
' (if the program runs 60 FPS, tb_movement_factor will be 1)
guyframe = guyframe + 0.09 * tb_movement_factor ' frame rotation (note how the speed of rotation is
' multiplied with tb_movement_factor)
IF guyframe > 6.5 THEN guyframe = 0.51 ' loop the frames (6 frames)
guybrush_x = guybrush_x + 2 * tb_movement_factor ' movement formula
IF guybrush_x > 660 THEN
walk_by_time = TIMER - start_walk_time ' when Guybrush goes off screen
start_walk_time = TIMER ' calculate walk-by time, reset the timer,
guybrush_x = -120 ' set him back on the left side of the screen
END IF
LINE (0, 0)-(639, 479), _RGB(255,255,255), BF ' Color the background white
_PUTIMAGE (guybrush_x, 140), frames&, 0, (3 + (CINT(guyframe) - 1) * 104, 0)-(103 + (CINT(guyframe)- 1) * 104, 155)
' Paste the proper Guybrush frame on the screen
' Print some variables on the screen.
LOCATE 1, 1
PRINT "FPS:"; fps
PRINT "time-based factor:"; tb_movement_factor
PRINT "walk-by time:"; walk_by_time
'_LIMIT 60 ' Rem/unrem to test different FPS
_DISPLAY
frames_per_sec = frames_per_sec + 1 ' count loops
timer_elapsed = (TIMER - start_time) ' calculate when one second passes
IF timer_elapsed > 1 THEN
fps = frames_per_sec / timer_elapsed ' when one second passes calculate FPS
frames_per_sec = 0 ' reset loop counter
start_time = TIMER ' reset start time (for 1 second formula)
END IF
LOOP UNTIL INKEY$ <> ""
Feel free to report your tests.
Mine:
Walk by time in FB: 6.512 sec (1040 FPS), 6.509 sec (60 FPS)
Walk by time in QB64: 6.539 sec (350 FPS), 6.539 sec (60 FPS)
A disadvantage of this method is that it breaks on low frame rates (objects moving with several pixels per loop speeds, animation skipping whole frames, etc), so you need to cap the maximum value of tb_movement_factor. If will make the game playable on low frame rates, but it will run slower than intended. Then again, no other method can help with this. Also, with really sensitive physics formulae you might get weird behaviour on ultra high FPS values. But really, use VYSNC or SLEEP in your programs and consider this method only as a fail safe of sorts when SLEEP or VSYNC fail to cap the program on the frame rate you intended (like 60 FPS).
I see no reason to avoid this method in conjunction with VSYNC and SLEEP as on targeted FPS values it will be nothing more than multiplying all your movement/animation/physics formula with a factor 1 or close to it, which basically has no effect. But in a chance your program ends up running with 40 or 1000 FPS on someone's PC because whatnot, variable time step method will do the job to make the game run as it does on 60 FPS. There might be some loss on computation speed, but I doubt it should be notable for the overall execution of your program. Maybe someone making a complex 3D or physics game with a lot of movement calculations can report how much variable time step method slows down his program.
Download the FB code compiled with the graphics file: time_based_movement_FB.zip
Download the QB64 code compiled with the graphics file: time_based_movement_QB64.zip
A tutorial written by Lachie D. (lachie13@yahoo.com ; The Maker Of Stuff)
