[Custom Movement] Slope Acceleration/Deceleration

You guys know I'm working on a Sonic engine for Construct, SO...

Okay, for starters, here's the current version of the engine.

Okay, so I've been trying to implement slope acceleration and deceleration, with pretty much no success whatsoever.

The Sonic Physics Guide (to be specific, this section) uses a "Slope Factor (slp)" that is used with "slp*sin(angle)" and added to Sonic's speed at the beginning of every step. The results of my attempts at implementing this method have been... Varied. The regular value for "slp", 0.125, does nothing at all. This is mainly because Construct's "Custom Movement Behaviour" works with much larger values (for example, Sonic's 'normal' acceleration is 450). Moving the decimal point around to the right once so it's 1.25 doesn't do anything either. Move the decimal point to the right again, however, and suddenly when Sonic is angled to the left he goes incredibly fast and when angled to the right he stops in his tracks, no matter which direction he's facing. Naturally, this is because clockwise from 0 degrees is positive and counter-clockwise is negative.

(Note that the default angle for when Sonic is NOT on a slope is 90 degrees. I merely reduce that by 90 when performing calculations.)

More complicated methods I've tried have not worked either. I might be doing the Physics Guide method wrong somehow, but why that would be so hasn't quite hit me yet.

If anyone could help me out, it would be very much appreciated. If any general programming guys might have an idea why I might be doing the Physics Guide method wrong, that would be awesome too.

You guys know I'm working on a Sonic engine for Construct, SO...

Okay, for starters, here's the current version of the engine.

Okay, so I've been trying to implement slope acceleration and deceleration, with pretty much no success whatsoever.

The Sonic Physics Guide (to be specific, this section) uses a "Slope Factor (slp)" that is used with "slp*sin(angle)" and added to Sonic's speed at the beginning of every step. The results of my attempts at implementing this method have been... Varied. The regular value for "slp", 0.125, does nothing at all. This is mainly because Construct's "Custom Movement Behaviour" works with much larger values (for example, Sonic's 'normal' acceleration is 450). Moving the decimal point around to the right once so it's 1.25 doesn't do anything either. Move the decimal point to the right again, however, and suddenly when Sonic is angled to the left he goes incredibly fast and when angled to the right he stops in his tracks, no matter which direction he's facing. Naturally, this is because clockwise from 0 degrees is positive and counter-clockwise is negative.

(Note that the default angle for when Sonic is NOT on a slope is 90 degrees. I merely reduce that by 90 when performing calculations.)

More complicated methods I've tried have not worked either. I might be doing the Physics Guide method wrong somehow, but why that would be so hasn't quite hit me yet.

If anyone could help me out, it would be very much appreciated. If any general programming guys might have an idea why I might be doing the Physics Guide method wrong, that would be awesome too.

Well, I can't help that much, but I can point in the right direction. Let me start by explaining that the behavior of being too fast to the left and stopping to the right is not correct. Look at this image:

No matter what angle value you use, you will always get the correct result. A is a 30? slope downhill to the left. B is a 30? slope downhill to the right. If you calculate the sin of the four green values (30, 150, -210, -330) it will always result in 0.5; and if you would have 30? uphill to the left or right (330, 210, -150, -30) it would always result in -0.5

If we use the slope calculation, slp * sin(angle) == 0.125 * 0.5, we get a value of 0.0625 and that value is added per step.

Now, what is a step in the original engine? Is it running at, let's say, stable 60 fps, and every step equals one frame? If so, the above value would result in adding 3.75 per second to the speed. That really isn't much, and if the speed is at something like 150 px per second, you will barely notice it.

But you said, that you raised some of the values of the original values. Be careful when doing so. Make sure, you raise them all by the same ratio. Then take that ratio and multiply it with the slope factor. For example, if the original 'normal' acceleration was 100, you used a ratio of 4.5 and your calculation would be

slp * sin(angle) * 4.5

With the example values above it would result in adding 16.875 per second instead of 3.75, which should be more noticable.

Also, if all of your movement is time based instead of frame based, while the original engine was frame based, you can't work with constant values. Instead you would then calculate the original values per second before using them. You would need to find out the frame or step rate. Example: slp = 0.125, steps per second = 60 >>> results in 7.5 * TimeDelta * sin(angle) * raisefactor

But back to my first point: If sonic is too fast to the left and stops to the right, then you're getting the wrong angles prior to the calculations. And make sure to convert all substracting and adding of angle values correctly. The original engine reversed all angles (45? are 315? in the original engine, 90? are 270?, 315? are 45?, etc. Or, in other words, they ablate the unit circle counter clockwise)

I hope, this helps a bit, I'm sorry that I explain it so complicated.

Hmm, never knew that guide existed, lol. Kinda makes me wanna tackle it just for the heck of it.

Okay, I think I get where you're coming from. Still...

The ratio business is, well, rather tricky. You see, the original acceleration wasn't even close to 100. It was 0.046875. Which means the ratio would have to be literally 9600. XD Yeah, the values for variables in the guide are freaking TINY. The slope factor is bigger than the acceleration!

Also, with angles, I guess all I have to do is just add 180 onto every angle calculation or something?

The ratio business is, well, rather tricky. You see, the original acceleration wasn't even close to 100. It was 0.046875. Which means the ratio would have to be literally 9600. XD Yeah, the values for variables in the guide are freaking TINY. The slope factor is bigger than the acceleration!

Well, 0.125 * 0.5 * 9600 = 600. Adding 600px per step doesn't make sense, agreed. But all those tiny values let me assume, the developers normalized them. Do you know, how many steps per second where used and what display size was used? I ask, because that 0.046875 makes sense somehow. For example, if the steps per second were 30 and the display width was 640, then 30/640 = 0.046875, or, if the steps were 15 and the width was 320, then 15/320 = 0.046875 I don't think this is coincidental.

But I have no clue how they would use such a ratio...

Also, with angles, I guess all I have to do is just add 180 onto every angle calculation or something?

Yes, either that or the logic should be adapted. I read something about converting the ground speed to x- and y-speed:

Xsp = Gsp*cos(angle);

Ysp = Gsp*-sin(angle);

If you would take it that way without adding (or substracting) 180 from angle, then the directions are inverted. Think of the 30? example. sin(30) = 0.5, but Gsp * -0.5 would get negative, so Sonic's Y position would lower (= he would walk upwards) while he should walk downwards. You may either do

Ysp = Gsp * sin(angle) or Ysp = Gsp * -sin(angle + 180)

but stick to one method throughout the game code, and make sure the angle you pass to the object's angle is a value in the range [0, 360]

EDIT: Just to stress that. The original is based on counter clockwise. That means you may only correct on the Y-axis, not on the X-axis!

Well, 0.125 * 0.5 * 9600 = 600. Adding 600px per step doesn't make sense, agreed. But all those tiny values let me assume, the developers normalized them. Do you know, how many steps per second where used and what display size was used? I ask, because that 0.046875 makes sense somehow. For example, if the steps per second were 30 and the display width was 640, then 30/640 = 0.046875, or, if the steps were 15 and the width was 320, then 15/320 = 0.046875 I don't think this is coincidental.

But I have no clue how they would use such a ratio...

Well, I'm not sure how many steps per second, the guide doesn't specify. But I believe it assumes the resolution is roughly 320x240, as the Genesis had a maximum resolution of 320?480. On the other hand, we're not working with Genesis hardware, so the number of steps and the screen size should be completely irrelevant, methinks... Which makes me still wonder how to apply pretty much any variable listed in the physics guide, really.

[quote:wwyf7ssh]Yes, either that or the logic should be adapted. I read something about converting the ground speed to x- and y-speed:

Xsp = Gsp*cos(angle);

Ysp = Gsp*-sin(angle);

If you would take it that way without adding (or substracting) 180 from angle, then the directions are inverted. Think of the 30? example. sin(30) = 0.5, but Gsp * -0.5 would get negative, so Sonic's Y position would lower (= he would walk upwards) while he should walk downwards. You may either do

Ysp = Gsp * sin(angle) or Ysp = Gsp * -sin(angle + 180)

but stick to one method throughout the game code, and make sure the angle you pass to the object's angle is a value in the range [0, 360]

EDIT: Just to stress that. The original is based on counter clockwise. That means you may only correct on the Y-axis, not on the X-axis!

Hmm... I'm not sure messing about with the X and Y speeds would do any good, looking at the base movement for the engine. The player's basic movement is based on an On Step thing reliant on two sensors, which automatically adjusts the player's angle and the direction of his horizontal speed. Unless I'm mistaken and changing the Y speed would be perfectly fine in this instance...

Don't get me wrong: All I said about angles only apply to code you copied from the original engine. Wherever you use you're own methods you are working with the clockwise model and therefore shouldn't inverse the angle. It was just an example of why you would need to change the code when copying from the original.

Btw, if you didn't take everything from the original, but rather found your own solutions, then you might also find your own slp value by just experimenting - it would be hard to tell, what values you have to use, if it is mixed that much with your own methods.

The problem of sonic powering up left slopes but not going up right slopes is because the wrong angle is being used with slp*sin(angle).

In the GeneralPlayer event sheet, events 126 and 130 you're using:

PlayerSprite.Value('SlopeFactor')*sin(PlayerSprite.Angle)[/code:9v70oopf]
PlayerSprite.Angle is perpendicular to the angle of motion (PlayerSprite.Angle-90), so change to be parallel:
[code:9v70oopf]PlayerSprite.Value('SlopeFactor')*sin(PlayerSprite.Angle-90)[/code:9v70oopf]

Holy crap I think I did it.

Basically, I shoved an action into the "On Step" event at the beginning of "Basic Movement" that adds "PlayerSprite.Value('SlopeFactor')*sin(PlayerSprite.Angle-90)" to the player's horizontal speed on every step, with the Orientation being PlayerSprite-90.

At FIRST, I thought I was doing it wrong, but I experimented with the value of SlopeFactor. 0.125 obviously does nothing. However, any value over 10 is right out, as it basically turns every slope into frictionless surfaces. 1.25 DID have a slightly noticeable effect, so I doubled it to 2.50, and comparing with the MMF version of Sonic Worlds, I discovered that Sonic's new slope speed was very close to the MMF version, not perfect, but very close. Thanks for the help, guys!

All I need to do now, basically, is adjust the SlopeFactor when Sonic is rolling, so I can finally implement rolling acceleration properly. This should be fairly-

[quote:17r45vmu]When Sonic is rolling uphill (the sign of Gsp is not equal to the sign of sin(angle)), slp is 0.078125 ($001E). When Sonic is rolling downhill (the sign of Gsp is equal to the sign of sin(angle)), slp is 0.3125 ($0050).

... Goddamnit. This is gonna be a tad tricky... Actually, on second thoughts, maybe moving the decimal point to the side by one and then doubling the resulting value would work...

Uphill = 0.078125 * 10 * 2 = 1.5625

Downhill = 0.3125 * 10 * 2 = 6.25

Holy crap it worked. I have proper rolling momentum. AWESOME.

Hi!

Link to the sonic engine is down, any chances of re-uping this one? Looks like the holy grail of slope management in cc.

Cheers!