I need to know this simple Metroid Question.

2007-04-10 12:02:26 am

After you collect the High Jump, how much does the jumping increase IN PERCENT FORM. please

Thread title:

2007-04-10 12:41:53 am

Well I was just playing and I figure that after you get the high jump boots you can jump about 2 blocks higher. 7 blocks with regular jump, 9 with high jump, so 100/7=14.285714, multiply that by 2 because you can jump 2 blocks higher with the high jump. That works out to be 28.571428.

My rough estimation is 28.57%

Why do you want to know this? You are up to something! You better fess up now that I told you!

JaggerG

2007-04-10 03:07:47 am

Shifty Leader

That M2k2 guy

You sure it's 7 blocks normally? I thought it had been slightly more than 4 blocks normally (minus one for a crouch jump, plus maybe half for a step jump). O_o

EDIT: MY BAD I am for some reason thinking MII. >_< Carry on. I'm gonna go in the corner and cry.

Yoshi348

2007-04-10 02:45:59 pm

PAGE BREAKER

Ready and willing.

THIS QUESTION IS WORTH 10 POINTS DO YOUR BEST

Prime Hunter

2007-04-10 05:06:38 pm

And yet... with the way we play Metroid games around here, most of us would probably fail miserably because we're not doing what we're supposed to. Kind of off in our own world so to speak...

mooseproduce

2007-04-10 08:08:39 pm

I wonder if it would be faster to do all jumps as a quick morph-unmorph jump. Y'know, of the kind where you can go through single blocks if you're standing under them.

+1 not-answering-the-question points.

mooseproduce

2007-04-10 09:22:18 pm

Ok, wait, a double-post for attempting to answer the question:

First I tried looking at the code, finding Samus' starting jump speed and gravity. I figured I'd stick the values into a quadratic equation, solve the first derivative for zero, and then find the value of the original equation at that x value.

Anyways, that failed:

Code:

Gravity for normal jump:
ldy #$18

Gravity for high jump:
ldy #$12

Hurdle #1: those obviously aren't in pixels. :'( Here's the jumping code, I believe:

Code:

        lda JoyFirst
        bpl +           ; branch if JUMP not pressed
LCD40:  jsr LCFC3
        lda #$12
        sta $0316

So I assume #$12 is the new upwards speed? Maybe? But that's the same as the gravity... besides, from playing the game and searching for cheats (I've found some awesome ones), I'm pretty sure Samus doesn't move in a strict parabola (at least, not an exact quadratic).

So that idea went down the drain. Plan B: the scientific approach! Here's my results:

The numbers to the right of "FCE Ultra" at the top of each window designate figure labels (figs. 1-6, if you will). Figures 3-5 show that Samus' upwards movement is 3 pixels on frame 1 of a jump, 4 pixels on frame 2 of a jump, and back to 3 on the third frame. Clearly, there's decimal values and crap going on which would have jived with my equation-solving method, so it's a good thing I gave that up. :P

Anyways, I overlaid a screenshot of Samus at the apex of her jump (fig. 2) with one of her on the ground, producing fig. 1. (With experimentation, I found that the collision code allowed for a one-pixel discrepancy with Samus' sprite on the ground; i.e. it is possible for Samus to be one pixel lower than she is in the screenshots. I made sure that this was not the case in the screenshots I used.) The results show an 82 pixel difference in height, using the top of Samus' head as a reference point (fig. 1). Problem is, I wasn't sure if the top of Samus' head moved in the sprite itself when she jumped; in fact, I suspected there to be a one-pixel difference. As shown in fig. 6, this is indeed the case; therefore, we adjust the 82 pixel count to 83, to correct for the shift in head location.

Figure 6 assumes that the "aiming upwards in midair" and "aiming upwards on ground" sprites do not shift. I'm pretty sure they don't, but if I wasn't getting so tired, I'd do a frame-by-frame comparison of jumping with and without aiming upwards, and see if the difference in upwards movement was equal (similar to figs. 3-5). But I am tired, so I won't. Also, I didn't do this for the high jump... but that would be easy, having already proven all the necessary things involving individual sprite heights. So basically, redoing figs. 1 and 2 (but with high jump) would be the only thing necessary to yeild a result. Also, because of the decimal values going on somewhere in figs. 3-5, Samus might concievably gain less/more height when jumping from one pixel lower.

Maybe tomorrow I'll check the aiming upwards/non aiming upwards jump sprites' head locations, and also find the pixel count for high jumping. And maybe check for the decimals thing.

CONCLUSION: A REGULAR JUMP GETS 83 PIXELS.

Ok, wait, a double-post for attempting to answer the question:

First I tried looking at the code, finding Samus' starting jump speed and gravity. I figured I'd stick the values into a quadratic equation, solve the first derivative for zero, and then find the value of the original equation at that x value.

Anyways, that failed:

[code]Gravity for normal jump:
ldy #$18

Gravity for high jump:
ldy #$12[/code]

Hurdle #1: those obviously aren't in pixels. :'( Here's the jumping code, I believe:

[code]        lda JoyFirst
        bpl +           ; branch if JUMP not pressed
LCD40:  jsr LCFC3
        lda #$12
        sta $0316[/code]

So I assume #$12 is the new upwards speed? Maybe? But that's the same as the gravity... besides, from playing the game and searching for cheats (I've found some awesome ones), I'm pretty sure Samus doesn't move in a strict parabola (at least, not an exact quadratic).

So that idea went down the drain. Plan B: the scientific approach! Here's my results:

[img]http://img.photobucket.com/albums/v607/mooseproduce/samus_jump_calc.png[/img]

The numbers to the right of "FCE Ultra" at the top of each window designate figure labels (figs. 1-6, if you will). Figures 3-5 show that Samus' upwards movement is 3 pixels on frame 1 of a jump, 4 pixels on frame 2 of a jump, and back to 3 on the third frame. Clearly, there's decimal values and crap going on which would have jived with my equation-solving method, so it's a good thing I gave that up. :P

Anyways, I overlaid a screenshot of Samus at the apex of her jump (fig. 2) with one of her on the ground, producing fig. 1. (With experimentation, I found that the collision code allowed for a one-pixel discrepancy with Samus' sprite on the ground; i.e. it is possible for Samus to be one pixel lower than she is in the screenshots. I made sure that this was not the case in the screenshots I used.) The results show an 82 pixel difference in height, using the top of Samus' head as a reference point (fig. 1). Problem is, I wasn't sure if the top of Samus' head moved in the sprite itself when she jumped; in fact, I suspected there to be a one-pixel difference. As shown in fig. 6, this is indeed the case; therefore, we adjust the 82 pixel count to 83, to correct for the shift in head location.

Figure 6 assumes that the "aiming upwards in midair" and "aiming upwards on ground" sprites do not shift. I'm pretty sure they don't, but if I wasn't getting so tired, I'd do a frame-by-frame comparison of jumping with and without aiming upwards, and see if the difference in upwards movement was equal (similar to figs. 3-5). But I [i]am[/i] tired, so I won't. Also, I didn't do this for the high jump... but that would be easy, having already proven all the necessary things involving individual sprite heights. So basically, redoing figs. 1 and 2 (but with high jump) would be the only thing necessary to yeild a result. Also, because of the decimal values going on somewhere in figs. 3-5, Samus might concievably gain less/more height when jumping from one pixel lower.

Maybe tomorrow I'll check the aiming upwards/non aiming upwards jump sprites' head locations, and also find the pixel count for high jumping. And maybe check for the decimals thing.

[color=red][size=18px][b]CONCLUSION: A REGULAR JUMP GETS 83 PIXELS.[/b][/size][/color]