Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Doing Game Gravity Right

niksula.hut.fi

Post reply on HN
Print view View original

61–70 of 86 posts

Re: Doing Game Gravity Right

#61

Post by rom16384 »

ori_b wrote: post #13

This is still Euler integration, which has poor accuracy whenever the derivative varies with time. The standard numerical integration method is 4th order Runge Kutta. RK4 is also popular for solving many forms of differential equations. A good summary is here: http://gafferongames.com/game-physics/integration-basics/

RK4 is indeed a popular and standard method. However for this particular equation or other equations with a conserved quantity a Symplectic integrator [1] should be used, as they are much better at keeping the numerical solution close to the real solution since they conserve the quantity of interest (energy, etc.).

[1] https://en.wikipedia.org/wiki/Symplectic_integrator

Re: Doing Game Gravity Right

#62

Post by jules »

pfisch wrote: post #6
mikeash wrote: post #5

Earlier quoted context omitted.

You'll have small variations at higher framerates too. Why not just avoid variation in this altogether? It's almost no extra work, and it makes things more consistent.

You're also using floats to store the values. This seems silly and looks like it will be slightly slower to calculate. Unless your game is running like garbage this will not matter. You are talking about a dt of something like 1/30 or 1/60

Floats are actually much faster than integers.

Re: Doing Game Gravity Right

#63

Post by podperson »

It's an interesting post, but perhaps a simpler way of looking at the whole thing is you should be using average velocity over the time elapsed rather than the just-calculated new velocity.

This becomes:

velocity_new = velocity_old + acceleration * time_elapsed

position_new = position_old + (velocity_old + velocity_new) * 0.5 * time_elapsed

It makes immediate, intuitive sense (at least it does to me) and doesn't require even thinking about differential equations (at least for constant forces).

Re: Doing Game Gravity Right

#64

Post by Gravityloss »

rom16384 wrote: post #61
ori_b wrote: post #13

This is still Euler integration, which has poor accuracy whenever the derivative varies with time. The standard numerical integration method is 4th order Runge Kutta. RK4 is also popular for solving many forms of differential equations. A good summary is here: http://gafferongames.com/game-physics/integration-basics/

RK4 is indeed a popular and standard method. However for this particular equation or other equations with a conserved quantity a Symplectic integrator [1] should be used, as they are much better at keeping the numerical solution close to the real solution since they conserve the quantity of interest (energy, etc.). [1] https://en.wikipedia.org/wiki/Symplectic_integrator

Interesting.

Especially the Leapfrog integrator seems cool:

http://en.wikipedia.org/wiki/Leapfrog_integration

Re: Doing Game Gravity Right

#65

Post by Gravityloss »

raldi wrote: post #60
Garoof wrote: post #49

Earlier quoted context omitted.

X is time, Y is height. So something like, X time after hitting the jump button, the guy is Y above the ground. (Or you can pretend that the guy is moving towards the right at constant speed, and jumping, and the points in the graphs are the different positions he'll be at :) (Edit: I'm not very sure about the pictures to the left though. Maybe higher jumps/longer time or somethingsomething.)

Yeah, I don't get the difference between the left and right sides of the two graphs either.

Maybe one is integrated with iterated velocity and one is with both iterated?

Re: Doing Game Gravity Right

#66

Post by stcredzero »

pfisch wrote: post #53
robertfw wrote: post #36

Earlier quoted context omitted.

I remember a car trick (do a barrel roll) in GTA San Andreas that for the life of me I could not accomplish. I found out that this variable physics was likely the problem - I dropped the graphics settings to minimum, and I was able to do the trick. This is on a quad core, 8GB ram, 1GB video card machine - it's no slouch - but the subtle difference was enough to make my task impossible.

Is this worth making the whole game run slower all the time for everyone? That is what you are talking about here.

Just between two save points. :)

Re: Doing Game Gravity Right

#67

Post by stcredzero »

jQueryIsAwesome wrote: post #57
pfisch wrote: post #52

Earlier quoted context omitted.

No I am just being realistic as an actual game developer. This is not a conceptual discussion. It doesn't make any sense to implement this change because if your fixed timestep for the physics system is breaking down then gravity not calculating correctly is the least of your problems. The controls would be unresponsive if the dt became large anyway. You are talking about more than doubling the number of operations f…

> the game is unplayably choppy anyway so it doesn't even matter. My point originally was about this statement of yours, that is purely conceptual and you skew the discussion to address the other part of your comment (or you through that was the point but didn't explain so in your answers) But anyway, one assumption is that every game should have a fixed gamestep, in many single player games (real single player games…

> in most online FPS if the server suddenly slows down all the players start experiencing lag and everyone looks like they are "teleporting"

Why would server lag effect FPS? I can only see how it would effect the reported positions of the other players because you aren't getting updates to changes in their movement. Server lag should never effect your FPS.

Re: Doing Game Gravity Right

#68

Post by jheriko »

teamonkey wrote: post #40
ori_b wrote: post #13

This is still Euler integration, which has poor accuracy whenever the derivative varies with time. The standard numerical integration method is 4th order Runge Kutta. RK4 is also popular for solving many forms of differential equations. A good summary is here: http://gafferongames.com/game-physics/integration-basics/

> This is still Euler integration Actually it's a form of Verlet integration, which performs much better than Euler's method while being much cheaper than RK4. Euler's method does not perform well with any form of acceleration and should not be used when acceleration is present. The equations here will remain accurate under constant gravity.

actually this is the 'midpoint' method. verlet is different in that it negates needing the first order term altogether, which is instead gotten at any instant from the previous and current position (zeroth order term).

but yes, verlet is much more powerful for game physics, especially when coupled with constraints since it allows all kinds of non-trivial behaviour (angular momentum) to fall out.

Re: Doing Game Gravity Right

#69

Post by talmand »

shabble wrote: post #59
lloeki wrote: post #46

Earlier quoted context omitted.

> This is still Euler integration, which has poor accuracy whenever the derivative varies with time. Which is why decoupling the physics delta from the rendering framerate is important. The author mentions Quake (id Tech 1, 2 or 3 ?), and I seem to recall id Tech 4 (Doom 3) was the first id Tech engine that implemented that.

I have a vague recollection that it was fixed or mostly eliminated in Quake 3. It was definitely still an issue in Quake 2, and one relatively well-known cheap trick was leading people towards particularly architecturally dense parts of the map and using a weapon such as the hyper-blaster, which was a high rate of fire laser gun for some unfortunate reason was implemented as a discrete particle/projectile for each sh…

And yet another reason why the serious competitors would turn off almost all graphics so that all you saw were colored boxes running around in colored boxes.

Re: Doing Game Gravity Right

#70

Post by ncallaway »

pfisch wrote: post #53
robertfw wrote: post #36

Earlier quoted context omitted.

I remember a car trick (do a barrel roll) in GTA San Andreas that for the life of me I could not accomplish. I found out that this variable physics was likely the problem - I dropped the graphics settings to minimum, and I was able to do the trick. This is on a quad core, 8GB ram, 1GB video card machine - it's no slouch - but the subtle difference was enough to make my task impossible.

Is this worth making the whole game run slower all the time for everyone? That is what you are talking about here.

This is incorrect. The suggested approach makes the game significantly more accurate adding 3 multiplications and an addition. This does not make the game noticeably slower. If you're concerned about 3 multiplications and an addition you're going to need to show me some profiler data that shows this as a specific bottle-neck in the game-logic.
Post reply on HN