Interesting article about gravity in games

[kikito]

Check it out if you are into that sort of thing:

http://www.niksula.hut.fi/~hkankaan/Hom ... avity.html

[substitute541]

Very interesting...

[Boolsheet]

One could call that a second-order approximation, right?

Accelerating physics are no longer approximation!

That's a dangerous statement. It's always an approximation unless we can throw an enormous amount of computation at it. Even then, we probably have to settle for a "accurate enough".

[kikito]

Accelerating physics are no longer approximation!

That's a dangerous statement.

Using the term "physics" is wrong there, of course. I think he means that the implementation is aligned with the conventional model used in games, while the "conventional" implementation, is more like an aproximation of that model. The "real" physical phenomenon is not even considered.

[Jasoco]

This actually explains the problem I had way back when I was creating my first sidescroller prototype and when my framerate would suddenly drop (For instance when my desktop picture would fade from one to another, Löve would have a tendency to drop its FPS to a very low amount) my player jumping would suddenly not be as perfect as it would with a constantly high framerate.

[Inny]

Interesting solution for the problem. I'm of the mindset that any degree of complex game physics should probably done quantized, i.e. that you do the world logic updates at a fixed framerate independent of the video framerate, and things like Box2d make this recommendation also (make a fixed timestep). But for simpler logic, I like this a lot, it has a strange elegance in its simplicity. Thanks for showing us this.

[dreadkillz]

Ah classical mechanics! Just a warning to readers, this method only works if the acceleration is constant. If your acceleration is a function of position or velocity, then you will need an approximate method or solve for the differential equation in another way.

[substitute541]

Just a note. It is still inaccurate for VERY low FPS. Just look at the new algorithm's picture, the 3 FPS example didn't even reach the correct position.

[Jasoco]

If you're getting 3FPS in a game, you probably won't enjoy playing that game anyway.

[Wojak]

I got something little different, but it seams to work just fine with low FPS:

Code: Select all

bullet.time = bullet.time + dt
bullet.speedy = bullet.speedy0 – 100*gravity*bullet.time
bullet.y = bullet.y  - bullet.speedy*dt

bullet.speedy0 is a initial velocity and it's constant for most of the time.
When an object interacts with something bullet.speedy0 is recalculated and bullet.time is reset

Exemplar in the attachment (left click outside the blue ball to create new object, you can move the blue ball with arrow keys, first blue number is FPS, the other is the object counter)