Physics are a very hard thing to pull off in a calculator program, but if you can get realistic physics to work, you will have a very impressive program. This is not to out-perform BuilderBoy's wonderful post on Omnimaga, but to clarify some points he may have made.

Inertia, the key behind how realistic movement is done, is represented as the previous motion. For example, if the object moved 5 pixels in the last frame, the inertia is 5. Inertia is what makes objects keep going. Programatically speaking, you need a single variable to store inertia for each axis (X and Y).

In my opinion, the best way to implement physics is by storing the position in one place, the inertia in one place, and the requested change in one place. Let me explain how this works. The requested change is the amount of force to apply to the object each frame. This means that if the user presses the right arrow, you would supply a reqested change of 1, 0, to move it right. The physics engine, or whatever is updating the location of objects, takes the requested change and adds the inertia (the previous motion) to it. It stores the resulting value back into the inertia. Then, it adds this value to the position, applying the motion.

Now, with this system, an object will go on forever in one direction, which is not good. This is where friction comes into play. Friction is the force that slows objects down. When two objects rub against each other, kinetic energy (movement) is changed to heat energy and the objects slow down. However, if you throw a paper airplane in the air, it eventually slows down as well. This is because of liquid friction, or the friction between objects and a liquid, such as water or the air. The easiest way to implement this programatically is to gradually lose inertia.

The last thing to implementing realistic motion is gravity. Once you have everything else in place, gravity is easy to add. You simply need to subtract one from the Y portion of the requested change.

So all of this may be a little confusing, so here is some psuedo-code:


Code:


This can be improved to support more of Newton's laws of motion, which I will post at a later time.

Very cool!

However, I think that velocity would be a more accurate term than inertia, as inertia is resistance to change in motion.

Here's my attempt, regarding balls because they are rotationally isopachous (so we can forget rotation), disregarding collision with other balls, all in partial pseudocode:

Code:

This can be improved to support more of Newton's laws of motion, which you will post at a later time.

Aye, and moving 5 pixels per frame, and staying that way, is resisting a change in motion, is it not?
Good job, I must say. Can't wait for more. (I'll read the code later )

I can't believe that I never noticed this post of SirCmpwn's before. I'm definitely going to need to look at that pseudocode more carefully, as calcdude said.

The gravity part is messed up. You have up and down reversed (as in, up causes you to go down, and down goes up).

Also, you can't force yourself to go down faster, nor can you "jump" in midair (and in that pseudocode, you can *only* jump when you are in the air - wtf?)

But really, the actual formulas for gravity and friction are fairly simple - just implement real physics for those two.

Whoops. I am not used to the Cartesian system in which Y points up instead of down.

What you're referring to as "jumping" was not meant to be jumping. It was supposed to be floating, as if a fan blew it upward.

Take this years-old Flash thing I made for example.

That's actually pretty impressive; I enjoyed playing with it for two or three minutes. I think I might have found one small math glitch, but I couldn't replicate it, so overall, cheers and well done!

The last thing to implementing realistic motion is gravity. Once you have everything else in place, gravity is easy to add. You simply need to subtract one from the Y portion of the requested change.