Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / timer based movement

Author
Message
haliop_New
User Banned
Posted: 3rd Dec 2014 08:49
can someone please walk me trough the idea of timer based movement ?
i already asked for this a couple of times but everytime i just dont get how it works.

any help will be highly appreciated .
Lucas Tiridath
AGK Developer
15
Years of Service
User Offline
Joined: 28th Sep 2008
Location: Kings Langley, UK
Posted: 3rd Dec 2014 09:21 Edited at: 3rd Dec 2014 09:21
Sure. So basically, timer based movement is where you use the actual elapse time, rather than the number of game cycles, to decide how fast your characters should move. Consider the following code.



The white square will move across the screen from left to right, but the speed of that movement is determined by the speed of execution. It will move 1 pixel to the right per cycle. That is, per time that SetSpritePosition(spr, GetSpriteX(spr) + 1, GetSpriteY(spr)) runs. This means that different processors will move the square at different speeds, depending on their execution speed. Equally if we modify the code as follows



the square moves slower, simply because it takes more time to complete a loop and so SetSpritePosition(spr, GetSpriteX(spr) + 1, GetSpriteY(spr)) runs less frequently.

The solution to this problem is timer based movement. The starting point for timer based movement is to know how far you want something to move over a given time. So say I want my white square to move by 100 pixels/second, I would write the following code.



The first thing I do in my loop is to calculate the delta time. This is the time that has elapsed since I last updated the position of the sprite. Given that I know that the deltaTime# value is in seconds, and that I want to move by 100 pixels a second, I simply multiple 100.0 by deltaTime# to work out how far I should have moved in the given timestep. The interesting thing about this is that if we re-insert our sleep like so



We will notice that the movement becomes visibly jumpy because of the huge delay between updates, but the actual speed of movement remains the same.

I hope that helps. Do let me know if you have any questions about any of this.

baxslash
Valued Member
Bronze Codemaster
17
Years of Service
User Offline
Joined: 26th Dec 2006
Location: Duffield
Posted: 3rd Dec 2014 09:25 Edited at: 3rd Dec 2014 09:26
Simple explanation:

Move = 10

Moving a sprite across the screen at 30 frames per second the sprite will move 300 units per second. At 60 fps it will move at 600 units per second.

ideal = 1/30
Move = 10 * (frameTime/ideal)

At 30 fps:

frameTime = 1/30 = 0.0333
ideal = 1/30 = 0.0333
Move = 10 * (0.0333 / 0.0333) = 10 * 1 = 10

10 units 30 times per second = 300 units per second

At 60 fps:

frameTime = 1/60 = 0.0166
ideal = 1/30 = 0.0333
Move = 10 * (0.0166 / 0.0333) = 10 * 0.5 = 5

5 units 60 times per second = 300 units per second

EDIT: Beat me to it...
paulrobson
9
Years of Service
User Offline
Joined: 22nd Nov 2014
Location: Norfolk, England
Posted: 3rd Dec 2014 10:55
This is much better.

The only improvement I would make is when you are calculating deltaTime max it out at 0.1s or so. If you have a pause or interstitial ad or something like that, deltaTime could come out with some sizeable value unwittingly which may cause objects to move a lot suddenly.
Funnell7
12
Years of Service
User Offline
Joined: 8th Sep 2011
Location: UK, England
Posted: 3rd Dec 2014 11:38
I just do this...

haliop_New
User Banned
Posted: 3rd Dec 2014 11:50
wow.
thank you i get it now.
now another question comes to mind will it work with physics ?i mean
when you use physics its kinda depend on the frame rate right? can this be manipulated to use with physics ?

(just ran your examples ,used the first one, the second did not worked)
paulrobson
9
Years of Service
User Offline
Joined: 22nd Nov 2014
Location: Norfolk, England
Posted: 3rd Dec 2014 12:49
No, physics usually has its own sets of velocities, but it will work in a similar way, it should run in 'real time' independent of the frame rate. Most physics engines provide a pause() method of some sort you can stop it if you want to.

Usually you either have to have objects driven by the physics engine or you do it yourself manually. There are advantages to both approaches.

Login to post a reply

Server time is: 2024-05-23 03:36:25
Your offset time is: 2024-05-23 03:36:25