I have noticed that a lot of programs still use
vsync set the timing of their programs, and there is nothing wrong with this approach. However, as soon as your program takes longer than 1s/60frames to finish a single loop the drop in the speed of animations becomes noticeable. So we need a timing method that is absolute, that is not tied to the clock cycle of the CPU. This is where
Millisec comes in.
I am sure everyone is familiar with measurements of time, but just to make sure one second is equal to one thousand milliseconds. Now we'll take a look at an example below a ball that travels moves across the screen
VAR BX,BY
BX=0
BY=120
VAR T,DELTA
T=MILLISEC
VAR LASTTIME=T
WHILE 1
'WAIT 5
'DELTA TIME IN SECONDS
DELTA=(MILLISEC-T)/1000
'UPDATE T
INC T,DELTA
'MOVE 50 PIXELS EVERY SECOND
INC BX,50*DELTA
IF BX+15>400 THEN
DEC BX,400
CLS
PRINT (MILLISEC-LASTTIME)/1000
ENDIF
WEND
When you run this you will see a ball move from left to right every 8 seconds. You can even try uncommenting the wait command and you should get roughly the same results, albeit with a noticeable drop in frame rate. I will include a code for a more complex program below which can draw 10 or even 1000 bouncing balls with no drop in the perceived timings of the physics.
One thing I would like to note is that
MILLISEC continues to count up even if the user has pressed the home button, so you can use something like the following to prevent unnecessarily large delta times.
'SOMEWHERE AROUND THE 2-4 SECOND RANGE IS ADEQUATE FOR MOST CASES
IF DELTA># THEN DELTA=#
Now this technique does not have to be applied to every situation, but if you are doing something physics related or you know that your application experiences lag from time to time, then this may be what you need in order to 'pretend' you have a smooth sixty frames per second all the time.
Also, you want to make sure you take the necessary precautions if you are applying this in a physics engine. One example of this is "collision tunneling" which will not detect a collision between two high speed and/or small objects and they will effectively pass right through each other. If you are interested in applying absolute timing to your physics based game, there is a wealth of resources related to the subject that can be searched. Just to give you an idea, SmileBasic allows you to specify a collision velocity which can be used to effectively resolve collisions between sprites.
Of course if your app is running less than five frames per second then optimization may be the route you are looking for ;)
Code:
252E724V
Instructions:
-Up/Down: increase/decrease number of balls (max/default 2000)
-A: reset(number of balls stays the same)
