Variable jump/animation speed based on running speed (with "lerp"?)

[Alessio]

Hi. This is more a math question, since, even if i googled countless times this without even finding a proper explanation.

In games like Super Mario World, you can see Mario's running/walking animation speed is almost perfectly synchronized with his running speed. Same with his variable jump height: the faster he runs, the higher he jumps.

Now, a not bad but rather long way to do it is setting that speed with multiple condition, in this way:

if hspeed >= 2  then image_speed = 1
if hspeed >= 3  then image_speed = 1.3
if hspeed >= 4  then image_speed = 1.6
if hspeed >= 5  then image_speed = 1.9

You may try the same with the jump height. Note that a friction/acceleration system is used so the character's movements are smooth like in a Mario game and not rigid like in a SEGA Mickey Mouse one.

Now, this may work but i'm pretty sure there is a more accurate way to do this.

I know about the "lerp" that returns an inbetween value between other two values based on a given interpolation amount. For example, in a horizontal speed value between 5 and 10, a percentage of 0.5 would make the lerp function return a value of 7.5. Same with a jump height value between 7 and 12, it would return 8.5. This is why the lerp function used between two objects' x coordinate causes a smooth camera movement (unless the percentage is 1, which would return the maximum value, or 0, where the minimum is returned and, therefore, the camera will not move at all).

Now i just would like to know how would you change that percentage value depending from the horizontal speed. I mean, we have this horizontal speed that has a minimum of 5 and a max of 10 and a percentage that has a minimum of 0 and a maximum of 1: those can't decrease beyond their minimum and viceversa. When the speed increases towards its maximum, also the percentage does towards 1 and viceversa. A graphical representation of what i mean:

5<->6.0<->7.0<->8.0<->9.0<->10 = Horizontal Speed
0<->0.2<->0.4<->0.6<->0.8<->1 = Percentage

... you get the idea, i hope. That percentage will be used as an interpolation value for the jump height and image speed variables, naturally so every one of these variables will be synchronized with the horizontal speed.

What are practical ways to do it? How do you make the percentage depend from the horizontal speed?

 

[Roderick]

Remember the formula y=mx+b from math class? Your examples are simple linear relations.

For example, your code block is essentially the same as

image_speed = 0.3 * (hspeed - 1) + 1;

 

[Khao]

What I have done before is just setting the image speed to match the hspeed, and then adjust with multiplication.

image_speed=hspeed*0.5

However, this is so much more simplistic than what you're doing that I can't help but think there's something I'm missing here.

 

[Yal]

How do you make the percentage depend from the horizontal speed?

percentage = abs(hspeed)/maxrunspeed;

Not any harder than that, really

 

[FrostyCat]

Here is a helper script that I include in all of my more recent experiments:

///relerp(oldmin, oldmax, value, newmin, newmax)
{
  return (argument2-argument0)/(argument1-argument0)*(argument4-argument3)+argument3;
}

It has many applications in view scaling, graphics placement and stat progressions, and as such it also finds a home here:

percentage = relerp(5, 10, abs(hspeed), 0, 1);

 

[Alessio]

percentage = abs(hspeed)/maxrunspeed;

Not any harder than that, really

To me it can be quite hard to grasp at first and i only figure it out when i see the actual calculation. Then, the "y=mx+b" math operation is something i've done in another form at school, effectively, but math classes in my school was the worst thing ever, blame to me for personal reason, blame to my already mediocre school and blame to a totally corrupt Ministry of Education. Now i have to learn everything again (even if i can remember most thing after a revision and can actually understand what i couldn't back when i was at school)... but that's off-topic.

In any case, that's exactely what i meant and what i did need! Thanks. Now what i wanted to do works perfectly!

And, plus: looking up at that kind of calculation I've stumbled into a command that is something like a "reverse lerp", which is something like "(variable - min) / (max - min)" which does exactely the same thing but works like the "lerp" function, except it finds the interpolation percentage given a variable rather than the position between two values given a percentage. It's dead useful and you can actually use this for a bunch of things! Just make it return 0 if both results of the subractions into the parenthesis are equal to 0, otherwise it will throw an error.

I even wonder if the "reverse lerp" will even be in GM:S2 as a built-in math function because it's really useful!

 

[Yal]

Just make it return 0 if both results of the subractions into the parenthesis are equal to 0, otherwise it will throw an error.

It should handle the "max - min = 0" case differently no matter what the other subtraction is, GMS does not take kindly in division by zero

 

[Alessio]

It should handle the "max - min = 0" case differently no matter what the other subtraction is, GMS does not take kindly in division by zero

Yeah exactely, i had a lapsus about it and forgot for a moment that a number can never be divided by 0. Because in the thing i've seen there was exactely the "if max = min" operation. Not even reality accept this division, it's something you learn at elementary school.

 

[Yal]

Yeah exactely, i had a lapsus about it and forgot for a moment that a number can never be divided by 0. Because in the thing i've seen there was exactely the "if max = min" operation. Not even reality accept this division, it's something you learn at elementary school.

Actually, most divisions by zero are okay as long as an infinite result is accepted (which isn't always the case since it doesn't always behave as you expect). Cases that are never defined, however, are inf - inf, 0*inf, inf/inf and 0/0 - these evaluate to different things depending on the origin of the infinities/zeroes, and sometimes don't evaluate at all. If a program lets you compute them, you get a NaN value, or "Not a Number".

The underlying format GM uses (double floats) supports expressing both infinity and NaN, but they're probably excluded from being valid in GM because of all the special cases that are associated with them and that it's easy to mess up computations completely if you let one slip through without noticing it's not a 'normal' number. For instance, NaNs are never equal to anything, including themselves.