Thread: Acceleration and time delta

  1. #1
    The larch
    Join Date
    May 2006
    Posts
    3,573

    Acceleration and time delta

    I'm wondering how one would calculate the velocity and displacement of accelerating game objects in a way that is aware of delta time.

    Currently I have the following (this is for a bounding circle of several particle-like objects that should move at the same speed but in different directions, to optimize collision checking):

    Code:
    speed *= acceleration
    attack_circle.r += (speed * delta_time)
    Where speed is displacement in millisecond (initially 0.21) and acceleration is a value close to 1 (here 0.98), which gives the effect of a circle expanding rapidly at the beginning and then reaching (almost) stand-still by the end of the effect.

    The problem is, it doesn't take delta-time into account when calculating the speed change, and hence, the slower the game actually runs, the further the circle expands.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  2. #2
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    Since acceleration = (delta speed)/(delta time), then you should be able to solve for delta speed to get (delta speed) = acceleration*(delta time).

  3. #3
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Ok. I printed out some computed values what happens at 60 fps in the game:

    Code:
     0.205800   3.430000 -0.004200 -0.00025200
     0.201684   6.791400 -0.004116 -0.00024696
     0.197650  10.085572 -0.004034 -0.00024202
     0.193697  13.313861 -0.003953 -0.00023718
     0.189823  16.477583 -0.003874 -0.00023244
     0.186027  19.578032 -0.003796 -0.00022779
    ...
     0.067745 116.174625 -0.001383 -0.00008295
     0.066390 117.281133 -0.001355 -0.00008129
     0.065063 118.365510 -0.001328 -0.00007967
     0.063761 119.428200 -0.001301 -0.00007808
     0.062486 120.469636 -0.001275 -0.00007651
    The first column is speed as currently calculated, the second is r, the third is speed difference between logic updates, and the fourth is acceleration calculated from your formula.

    So it appears that the (desired) acceleration is not constant, and the change of acceleration doesn't appear to be linear either.

    The math is getting quite hard. I wonder if I could find a linear equation to calculate the drop of acceleration, to approximate current behaviour, and hence get something like the following?

    Code:
    acceleration += acceleration * delta_time * some_constant
    speed += acceleration * delta_time
    r += speed * delta_time
    Last edited by anon; 10-18-2009 at 01:33 PM.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  4. #4
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    Not sure what you're modeling. If you're doing physics, then generally the acceleration is calculated from position, and you go from there. For instance, when I do spaceships going around a planet, the pseudocode looks like
    Code:
    direction_to_planet = spaceship.position - planet.position;
    acceleration = G * direction_to_planet / pow(length(direction_to_planet,3));
    spaceship.position += dt * spaceship.velocity;
    spaceship.velocity += dt * acceleration;

  5. #5
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Basically it is just a circular "burst" of some particles from a source. There's no real-world gravity here.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  6. #6
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,336
    Well, I can't say what formula governs your numbers since I don't know how you generate them. If you had some physical thing going on behind your particles, then that would give you your acceleration. If you like the picture you have and want to find a formula, it might not be a bad idea to load that file you have into a spreadsheet and run a regression on it and see what happens.

  7. #7
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Thank you. I think Excel should be able to figure out the formulas behind the values. Also, when it comes to physics, I think this might remind of friction (drag). And eventually, it won't need to be exactly the same, just as long as the result is the same at different FPS.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  8. #8
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    The method of simulating acceleration and velocity is always the same. The only thing that differs between games is the way the force is calculated.

    In vector math/pseudocode, this is how the update happens at each timestep:

    Code:
    UpdateAllForces();
    foreach( object )
    {
        object->Acceleration = object->Force / object->Mass;
        object->Velocity += object->Acceleration * deltaT;
        object->Position += object->Velocity * deltaT;
    }
    This is called the leap-frog Euler method. The part you have to fill in is UpdateAllForces(), which computes the net force on every object. The Acceleration, Force, Velocity, and Position quantites are all vectors.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  9. #9
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    The method of simulating acceleration and velocity is always the same. The only thing that differs between games is the way the force is calculated.
    Seconded. Computation of acceleration never changes but force calculation will change depending on what it is you are attempting to simulate. A = F/M is always correct. M here is always a scalar and F is where multitudes of calculations can come into play all resulting in a net force vector. The rest of brewbuck's code is essentially standard integration. There are several methods that can be used. The aforementioned Euler is the simplest but also the least accurate. There is also a modified Euler and a few other takes on it. The best one I've come across is Runge-Kutta and it is used in nearly every physics engine out there. Runge-Kutta can come extremely close to the real world counterpart. I would invite you to invest in some physics books for programming games.
    Last edited by VirtualAce; 10-19-2009 at 04:35 PM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Accuracy changes under different modes
    By sundeeptuteja in forum Tech Board
    Replies: 3
    Last Post: 07-08-2003, 11:02 PM
  2. Now's the time to try Allegro (newbie and pro alike)!
    By Justin W in forum Game Programming
    Replies: 19
    Last Post: 12-23-2001, 08:47 PM