View source for SPG:Jumping

{{SPGPages}}
'''Notes:'''
*''The research applies to all four of the [[Sega Mega Drive]] games and [[Sonic CD]].''
*''The following describes physics that only apply when the Player has no special power-up and is not [[SPG:Underwater|Underwater]].''
*''General airborne physics is detailed in [[SPG:Air State|Air State]]''.

==Constants==
{| class="prettytable" style="width: auto;"
!Constant
!Value
|-
|'''jump_force'''
|''6.5 (6 pixels and 128 supbixels)'' - ''6'' for Knuckles
|-
|'''gravity_force'''
|''0.21875 (56 subpixels)''
|}

==Jump Velocity==
Jumping is affected by the angle the Player is at when they do it. It can't simply set '''''Y Speed''''' to negative '''jump_force''', they need to jump away from the Ground Angle they're standing on. Instead, both '''''X Speed''''' and '''''Y Speed''''' must have '''jump_force''' subtracted from them, using cos() and sin() to get the right values.

More pseudo-code:
<syntaxhighlight>
X Speed -= jump_force * sin(Ground Angle);
Y Speed -= jump_force * cos(Ground Angle);
</syntaxhighlight>

Notice how the jump speed values are subtracted from the '''''X Speed''''' and '''''Y Speed'''''. This means their speeds on the ground are preserved, meaning running up fast on a steep hill and jumping gives you the jump speeds ''and'' the speeds you had from running up the hill, resulting in a very high jump.

===Variable Jump Height===
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?

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 '''''Y Speed''''' is less than ''-4'' (e.g. ''-5'' is "less" than ''-4'').  If it is, then '''''Y Speed''''' 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, the Player 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.

The check to see if the button is not being held is performed before the Player is moved to his new position and ''gravity_force'' is added to '''''Y Speed'''''.

===Bugs when Jumping===
Because the Player is moving from one action to another, at the same time as changing his [[SPG:Slope_Collision#The_Player.27s_Sensors|collision sensor arrangement]], and at the same time as changing speed and leaving the floor... some bugs can occur when launching from the ground and when landing.

Disturbingly, the game checks to see if you press the jump button before moving the Player. If you do press the jump button, it exits the rest of the cycle - so the Player doesn't move at all during the step in which you jump, vertically or horizontally.

[[Image:SPGJumpDelay.gif]]

This can mean that in the next step it can detect a release of the jump button and the Player will move up at a '''''Y Speed''''' of ''-4'' without having ever moved up at the speed of '''jump_force'''.

As described in [[SPG:Solid_Tiles#Sensors|Sensors]] the Player's sensor arrangement will change in size depending on what they're doing. When rolling/jumping, this arrangement becomes smaller. Whenever this happens, the Player will move up or down by ''5'' pixels to keep his bottom most pixel in the same position.
However when you are rolling and perform a jump, the Player's collision size ''incorrectly'' becomes it's standing size rather than the smaller rolling size. This in turn causes a few bizarre issues. 

Since while jumping the Player is in their ball form, they will still 'uncurl' when they land, and this involves setting the '''''Width Radius''''' and '''''Height Radius''''' to standing size and subtracting ''5'' from '''''Y Position'''''. This of course will simply move the Player's bottom most pixel up by ''5'' if their sizes don't change size. 
So, when the Player lands from this jump, it just assumes their '''''Height Radius''''' is becoming big again, so ''5'' pixels is subtracted from their '''''Y Position'''''. However because their size didn't actually change at all and the Player was already at floor level, they just rise ''5'' pixels above the floor instantly upon landing.

[[Image:SPGRollingJumpLandBug.gif]]

This results in them making contact with the floor, then being moved up ''5'' pixels then falling back down slowly via gravity.

==Sonic Mania Jump Differences==
[[Sonic Mania]] has extremely accurate classic Sonic physics, however some deliberate choices were made to modernise & smooth out the gameplay.

Note: ''While Mania changes things, the [[Retro Engine]] remakes emulate jumping more accurately.''

===Jump Height===
In [[Sonic Mania]], the Player has taller jumps than in the classic games.  For example, Sonic's jump will reach around 8 extra pixels high, and the entire jump lasts 2 frames longer. What causes this?

The jump force values are the same, however '''gravity_force''' is added to the normal value of '''jump_force''' used when applying the initial jump velocity, effectively cancelling the addition of gravity for that first frame. This gives the Player an extra frame of motion at either end of the jump arc. This applies to all characters.

===Jump Delay Fix===
In Mania, the jump delay bug shown above doesn't apply. The Player will begin to move upwards on the frame of pressing jump. 

[[Category:Sonic Physics Guide|Jumping]]