[DBP] - Timed movement function.

Author

Message

Cliff Mellangard 3DEGS

Developer

18

Years of Service

User Offline

Joined: 20th Feb 2006

Location: Sweden

Posted: 20th Apr 2011 00:30

Link

Made some updates to my timed movement function if anyone wants it?
I wanted an small single function to do it!
And it seams smooth and fast so far?

before loop write this!!

+ Code Snippet

type Timed_t  a as integer ,b as integer ,c as integer ,d as integer ,e as integer ,init as integer ,spd as float endtype
global Timed as Timed_t

Then put this at the top of your loop!!

do
Timed(timer())

code bla bla bla
code bla bla bla
loop

here is the function!

+ Code Snippet

function Timed(a#)
` Timed.e is how often to change speed (in milliseconds)/only used when the loop starts
if Timed.init=0 then Timed.a = a# : Timed.e = 1000:Timed.init=1
` don't change any of this!
Timed.b = a# 
inc Timed.c
temp = Timed.b - Timed.a
if temp >= Timed.e then Timed.spd = ((temp)/1000.0)/Timed.c : Timed.a=Timed.b : Timed.c=0 : Timed.d=1 : exit
if Timed.d = 0 then Timed.spd = ((temp)/1000.0)/Timed.c : exit
endfunction

then to move something simply use!
move sprite 1,60.0*Timed.spd
And remember that the value before *Timed.spd must be an float!

Its an modification of spookys timed movement

Back to top

Profile PM Website

Java Man

13

Years of Service

User Offline

Joined: 20th Feb 2011

Location: Australia

Posted: 25th Apr 2011 09:40

Link

Nice code, always like a good function to simplify coding

If I only had the time...

Back to top

Profile PM Website

Cliff Mellangard 3DEGS

Developer

18

Years of Service

User Offline

Joined: 20th Feb 2006

Location: Sweden

Posted: 26th Apr 2011 23:21

Link

Quote: "Nice code, always like a good function to simplify coding"

It only have some small flaws!
If the change is to rapid and large so could you still get an choppy movement .
I noticed this today when i rewrote my game engine that rapidly changes betwen 98-270 fps.

Back to top

Profile PM Website

Quel

15

Years of Service

User Offline

Joined: 13th Mar 2009

Location:

Posted: 9th May 2011 01:30

Link

First, it is called time based.

Second, this is one very perverted way of doing things, and i mean having an FPS value ranging to and from some so differing values! You just simply don't adjust 300 as a possible FPS for your game.

You need to decouple the loops, so there are two of them, one which syncs let's say 60 occasions a second, and the other one does the thinking side of your program without sync. This all can be achieved easily using the timer(), or for the best results maybe some plugin based more accurate timer command.

Time based movement comes in if the 60 fps cannot be maintained. Which is still okay, since with good smooth Time based movement, the slowdown shouldn't cause any trouble down to 24 FPS since that is the rate your brain can keep up with stuff happening in front of your eyes.

-In.Dev.X: A unique heavy story based shoot'em ~25%
-CoreFleet: An underground commander unit based RTS ~15%
-TailsVSEggman: An Sonic themed RTS under development for idea presentation to Sega ~15%

Back to top

Profile PM

WLGfx

16

Years of Service

User Offline

Joined: 1st Nov 2007

Location: NW United Kingdom

Posted: 11th May 2011 02:37

Link

I've just recently added this to my code which works. Doesn't need to be mega accurate, just so long as it works.

+ Code Snippet

function WL_TIMER_INIT()
    global WL_TIMER_CURRENT as integer
    global WLT_F as float
    WL_TIMER_CURRENT=timer()
endfunction

function WL_TIMER_GET()
    c as integer
    c=timer()-WL_TIMER_CURRENT
    WLT_F=c/16.666      ` rated at 60 fps
    WL_TIMER_CURRENT=WL_TIMER_CURRENT+c
endfunction

On each update I use WLT_F as my multiplier. At FPS of 60 the multiplier is 1.0, at 30fps it would be 2.0 and so on.

Warning! May contain Nuts!

Back to top

Profile PM Email Website

Cliff Mellangard 3DEGS

Developer

18

Years of Service

User Offline

Joined: 20th Feb 2006

Location: Sweden

Posted: 11th May 2011 17:40

Link

Quote: "First, it is called time based.

Second, this is one very perverted way of doing things, and i mean having an FPS value ranging to and from some so differing values! You just simply don't adjust 300 as a possible FPS for your game.

You need to decouple the loops, so there are two of them, one which syncs let's say 60 occasions a second, and the other one does the thinking side of your program without sync. This all can be achieved easily using the timer(), or for the best results maybe some plugin based more accurate timer command.

Time based movement comes in if the 60 fps cannot be maintained. Which is still okay, since with good smooth Time based movement, the slowdown shouldn't cause any trouble down to 24 FPS since that is the rate your brain can keep up with stuff happening in front of your eyes."

You are one weird dude?
In wich way is this perverted?
Show me wath you do that is so good and not perverted

You wrote that its wrong to have an locked sync rate and complained about the others in that threads solutions?
Show me wath you use to get smooth movement?
And thanks for the spelling lesson

Back to top

Profile PM Website

KISTech

16

Years of Service

User Offline

Joined: 8th Feb 2008

Location: Aloha, Oregon

Posted: 18th May 2011 22:17

Link

While Quel can be a little "harsh" with criticism, I have to agree that it's a very convoluted way of doing it.

This is the most common function I've seen in several other engines for Time Based Movement. (adapted for DBP of course)

+ Code Snippet


global flast# as float
global factor# as float

function tbm_update()
   diff# = timer() - flast#
   flast# = timer()
   factor# = diff# / 1000.0
endfunction

This is all you need. It's simple, and accurate.

move object x, speed# * factor#

Will move the object at a constant speed.

Decoupling the Display Loop from the Game Loop is what Quel was referring to. It allows your game to perform much better while maintaining a steady framerate. This especially helps with multiplayer games where you can't afford to miss any incoming data.

For situations where the framerate tends to fluctuate, you can do this.

+ Code Snippet


global flast# as float
global factor# as float
dim factors(51) as float

function tbm_update()
   diff# = timer() - flast#
   flast# = timer()
   factor# = 0.0
   for x = 1 to 49
      factors(x) = factors(x+1)
      factor# = factor# + factors(x)
   next x
   factors(50) = diff# / 1000.0
   factor# = (factor# + factors(50)) / 50.0
endfunction

This averages the factor# over 50 frames, so your object doesn't jump to it's new position just because the framerate dipped unexpectedly. After less than a second of steady framerate it will be in the right position. During that split second it will still be so close that the difference is negligible.

This also prevents a problem on fast machines where factor# can come back as 0.0 for several frames, which means nothing would move.

Back to top

Profile PM Email Website

Cliff Mellangard 3DEGS

Developer

18

Years of Service

User Offline

Joined: 20th Feb 2006

Location: Sweden

Posted: 18th May 2011 23:33

Link

Quote: "While Quel can be a little "harsh" with criticism, I have to agree that it's a very convoluted way of doing it."

I have used it since i learned it from spooky in 2004? if i remember it right

Its extremely smooth but you get weird speed spikes if the change is to large.
And it dosent affect any of the speed of data inside or outside the loop.

I have tryed something similar to the snippet you posted and always get very shaky movement when the framerate changes to much?

But i will try your code later on! as it could be something i have looked for.

Back to top

Profile PM Website

KISTech

16

Years of Service

User Offline

Joined: 8th Feb 2008

Location: Aloha, Oregon

Posted: 19th May 2011 19:23

Link

The odd thing about the code is it doesn't use an actual timer, which is why you get fluctuations when your framerate changes.

The function I'm using is based only on the amount of time that passes, so whether you are running at 2FPS or 2000FPS the object will move the same amount every second. Granted, at 2FPS you're going to see some jumps, but that is to be expected at such a low framerate.

Anything above 20-25 I think should produce smooth movement.

NOTE: For simplicity I used the timer() function in the code, but I would recommend the Matrix1Utils command hitimer() instead.

Back to top

Profile PM Email Website

Duke E

15

Years of Service

User Offline

Joined: 10th Mar 2009

Location:

Posted: 20th May 2011 13:43 Edited at: 21st May 2011 14:52

Link

Quote: "I would recommend the Matrix1Utils command hitimer() instead"

Or, from DBPro Version 7.7 you can use the performance timer without needing to get "Perffreq" from a dll or use IanM`s "hitimer()".

Like so:

+ Code Snippet

Do
    Cls
    Text 1,1 , "Timer()   :" + str$( Timer() )
    Text 1,15, "PerfTimer :" + str$( pTimer() )
    Sync
Loop
End

Function pTimer()

    // Returns "timer()" equivalent time from performance timer
    // Note: DBPro Ver. 7.7 (U77) or above only.
    Local pDivider as Double Integer
    Local pTime as Double Integer
    Local TimerNow as DWord

    pTime= Perftimer()*1000.0
    pDivider = Perffreq()    // Not in keywords yet, but the command compiles. Had to use a dll load call to get Perffreq before.
    TimerNow = pTime/pDivider    
EndFunction TimerNow

Regards

Back to top

Profile PM

Sorry your browser is not supported!

Code Snippets / [DBP] - Timed movement function.