Actions

SPG:Jumping

From Sonic Retro

Revision as of 19:30, 21 July 2018 by Lapper2 (talk | contribs) (fix italics mistake)

Notes:

Research applies to all four of the Sega Mega Drive games, and Sonic CD.

The following only applies when Sonic is out of water land with no special power-ups. Water physics, Super Sonic, and Speed Shoes will be covered in separate guides.

Variables

The following variables/constants will be referenced frequently in this section.

//Variables
xsp: the speed in which sonic is moving horizontally
ysp: the speed in which sonic is moving vertically

//Constants
air: 0.09375
jmp: -6.5
knxjmp: -6
top: 6
grv: 0.21875

Air Acceleration

When Sonic is airborne, he can accelerate twice as fast as on land (air).

There is no friction in the air (but there is a complicated drag effect that will be explained later), and pretty much, once Sonic has a certain xsp in the air, he'll just keep going at that speed until you tell him otherwise or he hits a wall.

Furthermore, there is no distinction for deceleration in the air, either, so pressing Left simply subtracts air from xsp no matter what, and pressing Right adds air to xsp.

Sonic's top speed (top) is the same in the air as on the ground.

Gravity

Gravity grv is added to ysp in every step in which Sonic isn't on the ground. It's what makes him fall downward when he runs off of cliffs. It's also what stops him from moving upward forever when he jumps.

Top Y Speed

In Sonic 1, Sonic's ysp does not seem to be limited. As he falls, grv' continues to be added to ysp, increasing indefinitely.

In Sonic CD, however, a limit was introduced so that ysp does not exceed 16 pixels per step. This limit is important so that Sonic never outruns the camera, or passes through solid ground because he's moving so fast per step that he never even collides with it. I believe it was introduced in Sonic CD because of the increased height in the design of levels such as Collision Chaos, and the endless vertical shaft in Tidal Tempest. Without the limit, Sonic would accelerate to ridiculous velocities in some of these areas and probably break the game.

ysp += grv
if (ysp > 16) ysp = 16

Air Drag

Each step Sonic is in the air, a special formula is performed on Sonic's xsp, but only if certain conditions are met. First, ysp must be negative. Second, ysp must be more than -4 (e.g. -3, or -3.5, is "more" than -4). Third, absolute xsp must be greater than 0.125. If these conditions are true, xsp is multiplied by a factor of 0.96875.

if (ysp < 0 && ysp > -4)
{
    if (absolute(xsp) >= 0.125) xsp = xsp * 0.96875;
}

Actually, this is just an approximation, and I'll explain why. Since the originals use 2 bytes for Sonic's speed value, where the first is pixels, and the second is sub-pixels, a speed of 6.5 pixels per step would be expressed with the hexadecimal value $0680. In decimal, that would be 1664. Clearly Sonic does not move over a thousand pixels per step! 1 pixel = $100 (256), half a pixel = $80 (128). Air drag in the original game is therefore something more like this:

if (ysp < 0 && ysp > -$0400)
{
    xsp -= (xsp div $0020); //"div" is division ignoring any remainder
}

If we were to perform the same calculation on our comparatively lower xsp values, which are always going to be lower than $20 (32), xsp will be completely unaffected. Why? Because any number lower than 32, when divided by 32, ignoring the remainder, results in 0. This is why the original game doesn't have to check if xsp is higher than a certain value before bothering to calculate air drag - if xsp is $001F or less, nothing will happen anyway.

A way to more accurately emulate air drag, then, is this:

if (ysp < 0 && ysp > -4)
{
    xsp -= ((xsp div 0.125) / 256);
}

The difference between the two methods, however, is pretty negligible, the second is just technically more accurate.

Air drag is calculated each step before grv is added to ysp.

Jump Velocity

Though we've become accustomed to it now, at the time Sonic the Hedgehog was first released, there were a whole lot of games that had fixed jump heights. No matter how quickly you released the jump button, the character would sail up into the air the same number of pixels. Games like Mario and Sonic were some of the first to have more variable and responsive controls, allowing for an improved sense of control over the character, and therefore a much more fun - and forgiving - gameplay experience.

So how does variable jump height work?

When Sonic is standing upon the ground, and you press the jump button, ysp is set to jmp (on flat ground, jumping at angles is further described in Jumping At Angles. The following still applies). In a game without variable jump heights, there would be no subsequent calculations besides gravity, and the character's velocity would be steadily depleted by gravity. The result would be a jump that lasted almost exactly 1 second and 100 pixels high. In fact, this is the kind of jump Sonic makes if you keep the jump button held until he reaches the apex of his trajectory. But the trick that allows variable jump height is all about releasing the button.

If the jump button is no longer being held, and you are currently jumping (in the air after pressing jump, not walking or rolling off the ground or pushed away by a spring etc), the computer checks to see if ysp is less than -4 (e.g. -5 is "less" than -4). If it is, then ysp is set to -4. In this way, you can cut your jump short at any time, just by releasing the jump button. If you release the button in the very next step after jumping, Sonic makes the shortest possible jump. This happens whenever you aren't holding the jump button and are currently jumping, not just on the release of the button.

In the step in which the computer detects the press of the jump button, Sonic doesn't actually move upward. Thus, in the next step it can detect a release of the jump button and Sonic will move up at a ysp of -4 without having ever moved up at the speed of jmp.

The check to see if the button is not being held is performed before Sonic is moved to his new position and grv is added to ysp.

Disturbingly, the computer checks to see if you press the jump button before moving Sonic. If you do press the jump button, it exits the rest of the cycle - so Sonic doesn't move at all during the step in which you jump, vertically or horizontally. This is lame, because xsp isn't lost, so he should continue to move. This flaw can be buffed out in a new engine.

Tails' jumping is identical to Sonic's, but Knuckles jumps a little lower. This is caused by a slightly smaller value for jmp, knxjmp.