Time-Based Acceleration

I can't believe I never came across this before. But I guess
I never
looked closely at using time-based animation with
acceleration. Here's
the issue.

I want to do everything time-based, independent of frame
rate. So each
frame, I calculate the time that has passed since the last
frame, and
then move game objects based on the time passed, rather than
"1 step".

Works great with velocity, of course. But introduce
constant
acceleration, like gravity, and you've got problems. Let me
illustrate:

Say you have downward acceleration due to gravity. Say
gravity is 4
pixels per second per second, vertically down.

At 1 frame per second, you would advance one step in a
second.
Downward velocity goes from 0 to 4. With downward velocity
at 4, the
location goes 4 pixels down.

At 2 frames per second, you would step every .5 seconds. So
at .5
seconds, downward velocity would go from 0 to 2 (half of 4).
Location
would then move down 1 (half of velocity). Then at 1 second,
velocity
would go from 2 to 4, and location would go from 1 to 3
(adding 2,
which is half of 4).

So in both cases, the velocity is 4 after 1 second. But in
the first
case, the position moves down 4, while in the second case,
the
position moves down 1+2=3!

At 4 frames per second, the velocity goes: 1, 2, 3, 4. But
the
position goes: .25, .75, 1.5, 2.5.

To make matters worse, the idea is that the times between
frames are
never exact slices of a second. They will vary with what is
going on.
So I can't simply say that each step is a certain time. That
would
defeat the purpose of time-based animation.

-- 
Gary Rosenzweig
CleverMedia
rosenzclevermedia.com
_______________________________________________
dirGames-L mailing list  -  dirGames-Lnuttybar.drama.uga.edu
http://nuttybar.drama.uga.edu/mailman/listinfo/dirgames
-l

The solution is quite simple. Your model should also include

acceleration, not just velocity. If you just
"move" objects according to 
velocity you can't get gravity right, because it's not
velocity, but 
acceleration. Now, when you've got that, you can apply the
time-scaling 
to _acceleration_ not velocity! (as i presume you've tried
to do)

I found this page on the subject floating nicely on the
net.

ht
tp://www.brainycreatures.org/physics/gravity.asp

-toni / sulake

Gary Rosenzweig wrote:
> I can't believe I never came across this before. But I
guess I never
> looked closely at using time-based animation with
acceleration. Here's
> the issue.
>
> I want to do everything time-based, independent of
frame rate. So each
> frame, I calculate the time that has passed since the
last frame, and
> then move game objects based on the time passed, rather
than "1 step".
>
> Works great with velocity, of course. But introduce
constant
> acceleration, like gravity, and you've got problems.
Let me
> illustrate:
>
> Say you have downward acceleration due to gravity. Say
gravity is 4
> pixels per second per second, vertically down.
>
> At 1 frame per second, you would advance one step in a
second.
> Downward velocity goes from 0 to 4. With downward
velocity at 4, the
> location goes 4 pixels down.
>
> At 2 frames per second, you would step every .5
seconds. So at .5
> seconds, downward velocity would go from 0 to 2 (half
of 4). Location
> would then move down 1 (half of velocity). Then at 1
second, velocity
> would go from 2 to 4, and location would go from 1 to 3
(adding 2,
> which is half of 4).
>
> So in both cases, the velocity is 4 after 1 second. But
in the first
> case, the position moves down 4, while in the second
case, the
> position moves down 1+2=3!
>
> At 4 frames per second, the velocity goes: 1, 2, 3, 4.
But the
> position goes: .25, .75, 1.5, 2.5.
>
> To make matters worse, the idea is that the times
between frames are
> never exact slices of a second. They will vary with
what is going on.
> So I can't simply say that each step is a certain time.
That would
> defeat the purpose of time-based animation.
>

_______________________________________________
dirGames-L mailing list  -  dirGames-Lnuttybar.drama.uga.edu
http://nuttybar.drama.uga.edu/mailman/listinfo/dirgames
-l

Gary Rosenzweig wrote:
> I want to do everything time-based, independent of
frame rate. So
> each frame, I calculate the time that has passed since
the last frame,
> and then move game objects based on the time passed,
rather than
> "1 step".
<...>
> Say you have downward acceleration due to gravity. Say
gravity is
> 4 pixels per second per second, vertically down...

Hi Gary,

It sounds as if you need to make your calculations with
reference to a fixed
point in space and time:

  displacement = initialSpeed * time + acceleration * time *
time / 2

Consider that "time" in the above expression is
"time elapsed since the
acceleration took its current value", then displacement
is "distance
traveled since acceleration took its current value".

If the acceleration changes, then you need to reset your
"start" points.

Does this make sense to you, or would you like me to knock
up a demo script?

James 

_______________________________________________
dirGames-L mailing list  -  dirGames-Lnuttybar.drama.uga.edu
http://nuttybar.drama.uga.edu/mailman/listinfo/dirgames
-l

 > I can't believe I never came across this before. But I
guess 
> I never looked closely at using time-based animation
with 
> acceleration. Here's the issue.
> 
> I want to do everything time-based, independent of
frame 
> rate. So each frame, I calculate the time that has
passed 
> since the last frame, and then move game objects based
on the 
> time passed, rather than "1 step".
> 
> Works great with velocity, of course. But introduce
constant 
> acceleration, like gravity, and you've got problems.
Let me
> illustrate:
> 
> Say you have downward acceleration due to gravity. Say

> gravity is 4 pixels per second per second, vertically
down.
> 
> At 1 frame per second, you would advance one step in a
second.
> Downward velocity goes from 0 to 4. With downward
velocity at 
> 4, the location goes 4 pixels down.
> 
> At 2 frames per second, you would step every .5
seconds. So 
> at .5 seconds, downward velocity would go from 0 to 2
(half 
> of 4). Location would then move down 1 (half of
velocity). 
> Then at 1 second, velocity would go from 2 to 4, and
location 
> would go from 1 to 3 (adding 2, which is half of 4).

It's not a problem: use the standard constant acceleration
formulas:

v = u + at
s = ut + 1/2 at^2

After 1 second, downward velocity is u + at = 0 + 4*1 = 4
pix/sec;
displacement is ut + 1/2 at^2 = 0*1 + 1/2 * 4 * 1 * 1 = 2
pix.

Of course, if your acceleration is varying too (eg with
rocket flight) then
you're into differential equation territory and it's a lot
more complicated.
But if it's cannonball-ballistics, you're okay.

Danny

_______________________________________________
dirGames-L mailing list  -  dirGames-Lnuttybar.drama.uga.edu
http://nuttybar.drama.uga.edu/mailman/listinfo/dirgames
-l

on testAcceleration()
  -- 1fps:
  t = [#distance: 0, #velocity: 0, #acceleration: 4]
  distanceOverTime(t,1)
 
  -- 2fps
  t = [#distance: 0, #velocity: 0, #acceleration: 4]
  distanceOverTime(t,.5)
  distanceOverTime(t,.5)
 
  -- 4fps
  t = [#distance: 0, #velocity: 0, #acceleration: 4]
  distanceOverTime(t,.25)
  distanceOverTime(t,.25)
  distanceOverTime(t,.25)
  distanceOverTime(t,.25)
 
end

-- x = x0 + v0 * t + 1/2 * a * t2
on distanceOverTime(a_ar_data, a_iTime)
  a_ar_data.distance = a_ar_data.distance +
a_iTime*a_ar_data.velocity + 
(a_iTime*a_iTime*a_ar_data.acceleration)/2
  a_ar_data.velocity = a_ar_data.velocity +
a_iTime*a_ar_data.acceleration
  put a_ar_data
end

wille

Gary Rosenzweig wrote:
> I can't believe I never came across this before. But I
guess I never
> looked closely at using time-based animation with
acceleration. Here's
> the issue.
>
> I want to do everything time-based, independent of
frame rate. So each
> frame, I calculate the time that has passed since the
last frame, and
> then move game objects based on the time passed, rather
than "1 step".
>
> Works great with velocity, of course. But introduce
constant
> acceleration, like gravity, and you've got problems.
Let me
> illustrate:
>
> Say you have downward acceleration due to gravity. Say
gravity is 4
> pixels per second per second, vertically down.
>
> At 1 frame per second, you would advance one step in a
second.
> Downward velocity goes from 0 to 4. With downward
velocity at 4, the
> location goes 4 pixels down.
>
> At 2 frames per second, you would step every .5
seconds. So at .5
> seconds, downward velocity would go from 0 to 2 (half
of 4). Location
> would then move down 1 (half of velocity). Then at 1
second, velocity
> would go from 2 to 4, and location would go from 1 to 3
(adding 2,
> which is half of 4).
>
> So in both cases, the velocity is 4 after 1 second. But
in the first
> case, the position moves down 4, while in the second
case, the
> position moves down 1+2=3!
>
> At 4 frames per second, the velocity goes: 1, 2, 3, 4.
But the
> position goes: .25, .75, 1.5, 2.5.
>
> To make matters worse, the idea is that the times
between frames are
> never exact slices of a second. They will vary with
what is going on.
> So I can't simply say that each step is a certain time.
That would
> defeat the purpose of time-based animation.
>

_______________________________________________
dirGames-L mailing list  -  dirGames-Lnuttybar.drama.uga.edu
http://nuttybar.drama.uga.edu/mailman/listinfo/dirgames
-l

Alternatively you could just go to a fixed-step system and
de-couple
your frame rate from your screen updates.

So for every frame that elapses you figure out how many
engine updates
to run, and act accordingly.

If your engine is running at 60 fps and you are only getting
25fps
then every frame would be roughly 2 engine updates (though
it could
occasionally be as low as 1 and as high as 3).

This way you can keep the simplicity of your previous
equations and
not have to worry about constantly recalculating against
your original
position.


-- 
Brian Robbins
Executive Producer and Gaming Evangelist
Fuel Industries - www.fuelgames.com
_______________________________________________
dirGames-L mailing list  -  dirGames-Lnuttybar.drama.uga.edu
http://nuttybar.drama.uga.edu/mailman/listinfo/dirgames
-l

> Alternatively you could just go to a fixed-step system
and de-couple
> your frame rate from your screen updates.
>
> So for every frame that elapses you figure out how many
engine updates
> to run, and act accordingly.

I second this approach.
I resisted it for a long time because it often meant
additional processing 
power (eg calculating say 3 game updates as opposed to 1
slightly more 
complex one) but now CPUs are faster it's just that much
simpler, and allows 
for nice things, like replays.
The other thing I found it useful for is you get a maximum
limit on certain 
things - eg collision detection. For example, in say a
racing game, you know 
the top speed of the car, and hence how far it can move in
one update, 
whereas with variable time spaces, you can't tell (unless
you clip your time 
delta to some limit). I can do optimisations as a result,
and it's much 
easier to code up (probably requiring no changes to your
current code at 
all, just the frame code that tell the engine how many times
to update).

Barry
gerbiltheburrow.co.uk 

_______________________________________________
dirGames-L mailing list  -  dirGames-Lnuttybar.drama.uga.edu
http://nuttybar.drama.uga.edu/mailman/listinfo/dirgames
-l

On 3/13/07, James Newton <james.newtonopenspark.com> wrote:
>   displacement = initialSpeed * time + acceleration *
time * time / 2

That was the key, of course. Silly me to forget to use a
physics
formula when trying to simulate physics.

This works fine despite the fact that I can't use a
"fixed" starting
point. I can't, because the player has control over the
objects, so
acceleration can be altered at any time. But this works fine
if you
think of the "initialSpeed" as the
"previousSpeed" and the "time" as
the "timeDifferenceFromLastStep".

Thanks.

-- 
Gary Rosenzweig
CleverMedia
rosenzclevermedia.com
_______________________________________________
dirGames-L mailing list  -  dirGames-Lnuttybar.drama.uga.edu
http://nuttybar.drama.uga.edu/mailman/listinfo/dirgames
-l