Inertia

[sidcrazy]

Hello everyone, I am working on a friving games and thanks to tutorials I now have floating point variables. But I am having problems simulating Inertia. Any advice would be greatly appreciated!

 

Thanks,

[Rybags]

An cheap and easy way to do inertia is to have a table of velocity values.

 

It would hold values going from maximum negative through to slowest negative, stationary, then up through from min to max positive.

 

Then all you need to do is maintain an index variable which generally changes depending on joystick input. If you choose, you can have it float back towards centre to simulate slowdown if there's no joystick input for that axis. Naturally you do bounds checking so you don't try to reference outside the array.

 

If you're doing the movement at 50/60 FPS then you'd probably want to use duplicate entries, e.g. to move from maximum negative to max positive in a table with only 11 entries would only take about 1/5th second in PAL.

Edited December 15, 2013 by Rybags

[sidcrazy]

Thanks Rybags. But I was wondering if you or anyone else had a formula for interia? The table logic idea is great, and that would cut down on a lot of having multiple switches.

[bogax]

force = mass * acceleration

 

or

 

acceleration = force / mass

 

keep a velocity

apply an acceleration proportional to force and inversely

proportional to mass

 

so if you move the same thing with twice the force

use twice the acceleration

 

if you move something twice as big with the same force

use half the acceleration

 

etc

 

basically mass is inertia

 

both force and acceleration are directional

so you'll presumably have both x and y components

 

you might need some trig to figure them

Edited December 16, 2013 by bogax

[Rybags]

Using pure physics calculations is somewhat cumbersome and overkill in most situations.

 

Another possibility is to use binary fractional techniques for velocity (which my table method would use anyway).

 

As an example, you have 2 bytes per H/V axis to represent velocity.

 

High byte, use the msb to represent direction (forward or back). Remainder of the byte can represent how many pixels per frame the movement is.

 

Low byte is the fractional part. Maintain a working accumulator variable then add the low byte to this variable. If it exceeds 255 then the carry gets set and you add that to your high byte value for just that particular move cycle.

 

Of course this is assuming Assembly Language, higher level languages are somewhat different and you can accomplish with less coding in most cases.

 

For inertia using the fractional binary method, you simply increase or decrease the velocity component by set amounts when the joystick direction or other condition dictates.

Of course, employ a bounds check so the velocity doesn't go too high. Have the increase/decrease amount set to a constant so that it's possible to return to zero (no motion). Or just have a "dead zone" where e.g. if the velocity decreases to a sufficiently small amount you just zero it in the program.

[bogax]

Using pure physics calculations is somewhat cumbersome and overkill in most situations

 

 

You're going to want them in there somewhere.

 

Building them into tables seems perfectly reasonable,

especially if things are complicated enough to need

some trigonometery

 

 

 

Another possibility is to use binary fractional techniques for velocity (which my table method would use anyway).

 

Sounds like a good candidate for 8.8 variables/math

Edited December 16, 2013 by bogax

[enthusi]

Actually this really is very simple as already mentioned in the former posts.

Its simple math and you dont need physics at all. Physics tell you that there IS inertia.

Each 'frame'/step change your position x, y according to your current speed dx, dy.

When you move, or now, rather accelerate, dont act on x,y directly but on dx, dy.

x=x+dx

y=y+dy

 

x and dx can and should be fractional of course.

Now implement:

if joy pushed right:

dx = dx + STEP

 

STEP can be a constant(!) and will represent the amount of acceleration.

I.e. a constant dy of 9.81 m/s^2 will simulate earth's gravity (of course you would not want SI units in the end).

 

That's it.

Its hardly more complex than the non-inertia approach.

[+Gemintronic]

Since bB cannot properly handle negative numbers I sometimes parcel out the velocity into four variables:

 

nspeed sspeed wspeed and espeed

 

Not the most elegant or efficient solution but it keeps things simple.

[Rybags]

That's OK anyway, in Assembly you generally either check and convert to suit 2s complement maths or execute a different piece of code per direction.

 

Inertia technique can also be used for stuff like platform characters skidding on ice - you don't necessarily even have to use differing velocities, the table approach can simulate delayed stop/directional change for such simulated surfaces.