Live data from Hacker News

Doing Game Gravity Right

niksula.hut.fi

31–40 of 86 posts

Re: Doing Game Gravity Right

#31
post #23

you are still doing it wrong. dt should not be affected by framerate. http://gafferongames.com/game-physics/fix-your-timestep/ use an accumulator to have a fixed dt no matter the framerate. With a variable step size you risk all kinds of weird bugs linked to the hard to debug rendering context. The size of dt should be consider a system parameter, tuned for your game and fixed in concrete .

So what happens when the OS doesn't return to your process in dt time? The whole point of dt is to deal with variable framerate.

When your game does regain control, it can run the simulation for N steps (however many it usually does for the given dt), then finally render the scene using the latest state. (so the game will appear to pause, then skip ahead). Or it can try to play catch-up, it does 1 tick and render at a time, but with a reduced delay between frames until it's "caught up". (so the game will pause, then appear fast-forwarded for a bit).

Either way Tlark is right, you really don't want the game logic to be affected by framerate.

Re: Doing Game Gravity Right

#32
For other simple methods of numerical integration, look at the Trapezoidal Rule and Simpson's Rule, two staples of high school (or college) calculus.

Since we're talking about gaming, it bears noting that Box2D (and most physics engines, for that matter) uses the Semi-implicit Euler method (http://en.wikipedia.org/wiki/Symplectic_Euler_method). The author of Box2D mentions that this is a better method than Verlet integration because calculating friction requires knowing velocity.

Re: Doing Game Gravity Right

#33
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/

Correct me if I'm wrong, there is no reason to numerically integrate this. This is not a differential equation. The integral solution is a simple function that can just be evaluated.

Maybe there are other forces? Like air friction? I'm just guessing.

Re: Doing Game Gravity Right

#34
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/

Correct me if I'm wrong, there is no reason to numerically integrate this. This is not a differential equation. The integral solution is a simple function that can just be evaluated.

Leaving it as a differential equation gives you some room to experiment more easily. For example, suppose you want to add a swimming mechanic to your game: you might end up with a completely different closed form solution, but if you left it as a differential equation it could just be a couple extra additive terms.

Re: Doing Game Gravity Right

#35
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/

Just a note here that this person's blog is utterly amazing for folks just getting into game physics-related programming. All the articles are gold.

Re: Doing Game Gravity Right

#36
post #4

Why does this even matter? If you have a large delta time then your game is fucked anyway. Collision detection will likely also be broken and the game is unplayably choppy anyway so it doesn't even matter.

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.

Re: Doing Game Gravity Right

#37
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/

Verlet Integration is another way to solve this kind of DE (i.e. DEs related to kinetics) quickly and time-reversibly... https://en.wikipedia.org/wiki/Verlet_integration

[deleted]

Re: Doing Game Gravity Right

#38
post #7

Earlier quoted context omitted.

Drops in framerate happen. Why not make a best effort for accuracy? Also, it's interesting and insightful.

> Drops in framerate happen. No, they don't. Game logic should run at constant 60 or more fps, even when graphics framerate is lower: http://gafferongames.com/game-physics/fix-your-timestep/ But yes, it's an interesting article, and this method allows for a bit more accuracy.

So, why is it important to have a fixed deltaTime? Except in cases where determinism really does matter. I.E. lock-step based networking. Why is this important?

Re: Doing Game Gravity Right

#40
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.

Post reply on HN