# Thread: Gravity calculations for falling object

1. ## Gravity calculations for falling object

I need a little direction on how to handle gravity.

What is the best way to implement acceleration due to gravity for a falling object? More specifically, how should each check/iteration on the object be done, if it should be done in that fashion?

h = 16t^2 + s can be used to calculate how many seconds the object will take to fall, and the objects height at any given second.

Would it be best to do a check every... say, 1/10th, or 1/100th of a second and place the object where it would be according to the formula, or would this approach be completely wrong?

I'm interested to know the different ways to accomplish this, but haven't been able to find anything substantial regarding this using google. Thanks for any replies.

2. Gravity is a force with the acceleration of 9.82 m/(s^2).

I would place the object at the startingpoint with a velocity of 0, then for every frame, calculate the time that passed since last frame was rendered (calling this deltaTime), increase velocity with 9.82*deltaTime, move object with velocity*deltaTime towards the point of gravity.

3. Originally Posted by Shakti
Gravity is a force with the acceleration of 9.82 m/(s^2).

I would place the object at the startingpoint with a velocity of 0, then for every frame, calculate the time that passed since last frame was rendered (calling this deltaTime), increase velocity with 9.82*deltaTime, move object with velocity*deltaTime towards the point of gravity.
Would you include every single pixel as a step when moving the object toward the point of gravity or is that overkill or even practical?

If every pixel on a 800x600 screen was modeled as one foot, for instance: As an object fell for two seconds it has fallen ~64 pixels. Between the second and the third second, it has fallen ~80 pixels for a total of 144 pixels. For these 80 pixels, I suppose I would use that a a divisor to my timer increment if I were not dealing with frame rendering?

Would I increment a pixel every 0.0125 seconds for this example? I'm not sure how accurate I need to be?

4. it should be updated each frame

5. I used a 10 millisecond deltaTime wait between each redraw of the object, and increased the velocity by 9.82*deltaTime each frame.

Thanks for the help.

6. After implementing collision detection, timing for animation, and a few other things, I've realized that the way I implement gravity doesn't fit in with my collision detection.

... the reason being, is that due to acceleration, the objects which are falling "skip pixels" in their decent, which causes them to fall past the bounding tops of certain items which they should be impacting.

For the "ground" I've been checking if the next iteration of y movement will be past the ground, and if it is, add a bit to acceleration, and then put the character on the ground instead. This method won't quite work for all of the other tiles and objects I've implemented.

How does one normally deal with this problem?

7. calculate the time that passed since last frame was rendered (calling this deltaTime), increase velocity with 9.82*deltaTime, move object with velocity*deltaTime towards the point of gravity.
This is the only way to do the calculation correctly. You must process each frame based on the timeDelta between frames. Anything else is some very screwed up integration.
Listen to the answers you have been given instead of insisting on your own methods which are clearly incorrect. At 60 FPS each frame is taking 16.6667 ms to render and update. At 30 it is taking ~32 ms to update and render. 10 ms is a lot of time to waste and is incorrect. Physics normally runs at 30 FPS while rendering runs as fast as possible. In 60 hz vsync the render runs at 60 FPS and the physics runs at roughly half that to ensure the math doesn't get wonky.

8. Simple.

Move the object, check for collision, if there was a hit, move the object to its previous location. If there was no hit, move onto the next object. You should update this each frame. The calculations for collision and the effects of gravity are so small they will cause no slowdown, unless you have 5000000 objects you are doing the calculations for, then you are screwed no matter what.