This page is a mirror of Tepples' nesdev forum mirror (URL TBD).

# Jumping

how have you guys handled jumping? here's my routine:

Code:
SubPlayerJump:   ldx playerJumpPtr
cpx PJUMPPTRNULL        ; if(playerJumpPtr >= #11)
bcs ExitPlayerJump      ;    exit jump routine
cpx #00                 ; if(playerJumpPtr == 0)
beq playerStartingJump      ;    skip over the ground check

lda Player1_Y1          ;
clc                     ; check if the bottom of Pitfall
adc #24                 ; Harry's sprite is touching
cmp GROUNDLEVEL         ; the ground on either level of
cmp TUNNELLEVEL         ; exit the routine
beq ExitPlayerJump      ;

playerStartingJump:   ldy #00
loopUpdateMorePX:   lda Player1_Y1, Y
clc
sta Player1_Y1, Y
iny
iny
iny
iny
cpy #\$18
bne loopUpdateMorePX

inc playerJumpPtr
ExitPlayerJump:   rts

playerJumpTable:   .db \$F8, \$00, \$FC, \$FE, \$FF, \$00, \$01, \$02, \$04, \$00, \$08

it works, but it's hard on the eyes. playerJumpPtr is set to \$00 when 'A' is pushed, and is increased every frame until it hits \$0B. the "jump" bit in the player status is cleared at that point, and playerJumpPtr is ignored.

gravity has no effect while the "jump" bit is set, and the only thing that can interrupt the jumping process is collision with a vine.
Balloon Fight and Super Mario Bros. are based on Newtonian kinematics. For each actor, store a (fixed-point) position and a (signed fixed-point) velocity. When the actor is in the air, add a constant to velocity every couple frames, which represents the force of gravity. Then add velocity to displacement every frame for Newton's first law. To make an actor jump, set the velocity to an upward value; the value changes the height of the jump.
Yeah, this is somewhat as I like to do it. I have 2 variables that represent vertical and horizontal speed. These are added to the player's coordinate every frame. The controller (left and right directions) has no direct effect on the player's coordinates, but on the horizontal speed variable. If no direction is pressed, this variable moves towards 0 every frame (deacceleration).

The same happens with vertical speed. This is constantly increasing, as effect of gravity, but floor under the player keeps it from falling. If there is no floor, he will fall. To jump, I set the vertical speed to a big negative number, having the player suddenly move up, and as gravity slowly modifies this number towards positive values the playe will eventually stop going up and start going back down, effectivelly completing the jump.

It's been a while since I have last used this method, but it looked good as far as I remember. I'll try this again in my current project, if it looks and feels right I'll stick to it.
Yeah, velocity-based jumping is definitely the way to go - simpler methods just feel so fake. Depending on the game, velocity-based horizontal motion can work well too (SMB, again.)
commodorejohn wrote:
Yeah, velocity-based jumping is definitely the way to go - simpler methods just feel so fake.

But I consider the velocity-based way to be quite simple too... simpler than, say, a scripted jump, that seems to be somewhat popular.

With the velocity-based approach, you simply don't handle the jump as a whole (as many other methods do), you just provide an initial impulse, which happens to be how real jumps work, which is good.

Quote:
Depending on the game, velocity-based horizontal motion can work well too (SMB, again.)

I agree. This is not for all kinds of engines.
tokumaru wrote:
...With the velocity-based approach, you simply don't handle the jump as a whole (as many other methods do), you just provide an initial impulse...

yeah, the above aproach is becoming a nightmare to maintain. not to mention it's useless for any other object besides the player. im gonna try a velocity-based routine and see how it works out.

commodorejohn wrote:
Yeah, velocity-based jumping is definitely the way to go - simpler methods just feel so fake.

pitfall!'s jumping is kinda rigid looking anyways, so i'll have to find a happy medium.
tokumaru wrote:
With the velocity-based approach [...] you just provide an initial impulse, which happens to be how real jumps work, which is good.

Real jumps in a video game would rule out any significant platform action, unless you're simulating a real jump where there's less gravity than on the moon. And even then this eliminates jump height control, which adds a lot to a platformer.
I'd recommend also making gravity have no effect on the player's jump for the first 1/2 second or second while he/she is holding down the jump button. This ought to simulate the familiar "hold down for a high jump, tap button for a low jump" pattern that we're used to.
ccovell wrote:
I'd recommend also making gravity have no effect on the player's jump for the first 1/2 second or second while he/she is holding down the jump button.

This is a very good idea actually.

And blargg, by "real" I mean the way the thing works, not the exact same values as the real world. The values in games are tweaked for higher jumps, but the idea is the same.
ccovell wrote:
I'd recommend also making gravity have no effect on the player's jump for the first 1/2 second or second while he/she is holding down the jump button. This ought to simulate the familiar "hold down for a high jump, tap button for a low jump" pattern that we're used to.

Yeah. Fail to do this (plus latch the left-right button value), and get horrible Castlevania controls.
As opposed to Mario Bros. (1983) controls?
yeah mario bros is pretty bad. i started a clone back in '04 in an attempt to fix the controls (to be more like the smb3 version) and add more depth to the gameplay. somewhere along the line i lost the source and gave up, and then a few weeks ago i found it on an old backup cd-r. the code was pretty bad, but im might continue the project.