DK Jr. springboard discussion

[marinomitch13]

These findings make sense out of the data. I was gonna respond to Dean, but then I realized that the math wasn't adding up to what people have actually and certainly experienced, so I was leaning towards questioning some of the assumptions that I had previously been running on (mainly the content of Zerst's findings).

All is well in the world again -especially cuz Dean got a new WR tonight too!

However, just to be fair, I have to wonder if maybe Dean actually has some sort of rare harder rom version of the spring jump. That would be the remaining thing we ought to check.

[ChrisP]

Well, the other night in Allen's stream Zerst also said (with a lot of confidence) that with an 8-way joystick one can climb and steer barrels at the same time in DK, which is something that I thought had been conclusively debunked.

I've played with an 8-way and I've certainly never been able to do that. (All I've ever been able to do with an 8-way was run off edges when trying to climb.  )

Not to pick on Zerst, but according to him, he barely even plays DK (with a 4-way, 8-way, or anything else) so I'm not sure why he felt so certain.

In any case, the stuff about the springboard frames was accepted rather uncritically from him, and if he was mistaken about the climb-steer (which I'm pretty sure he is), he might have been mistaken about this too. Anybody can misinterpret code.

[marinomitch13]

Well, the other night in Allen's stream Zerst also said (with a lot of confidence) that with an 8-way joystick one can climb and steer barrels at the same time in DK, which is something that I thought had been conclusively debunked.

Yeah, I was there for that. I'm pretty sure I remember just testing this sort of thing in mame, bitd, and you actually can't utilize both inputs at once. The first input actually has to be stopped for the next one to happen. Regardless, Zerst is actually the only person I've heard not say that two inputs at once was impossible on DK.

[Graham Wolfe]

just played a kill screen game on mame with 20 successful spring jumps in a row (only missed a jump on the very first springboard) but i died on a springboard stage and made the jump first try again on it.

was using double tap method on keyboard

its all about feeling the jump =)

[JCHarrist]

Here's my code breakdown for the superjump. I don't guarantee that all of this is 100% accurate but I'm confident that the routine that polls the jump button and updates Junior's position while on the spring was intended to run every other frame.

Memory location $6A90 was set up for just this purpose and the first few lines of code from 4D6C to 4D79 handle the frame skipping.


Relevant memory locations:

$6010 = input from joystick and jump button: 01=right:02=left:03=down:04=up:80=jump:81=right jump:82=left jump

$6203 = Junior's X position

$6205 = Junior's Y position

$620F = ?? not sure.. sprite # maybe??

$6667 = spring position. 50=fully extended....53=fully compressed.

$6A87 = 1 if Junior collision with with spring detected else 0

$6A89 = 0 if spring on downstroke or bottom. 1 if spring on upstroke

$6A8A = normally 0 or 54 but records spring position from which superjump was successful = 51,52,or 53.

$6A8B = 1 if Junior on spring else 0.

$6A90 = alternates between 0 and 1 every frame

$6A9F = direction Junior was moving when he hit spring. 1=right: 2=left

Code: [Select]


Arrive here from 5816 when Junior is on spring:

4D6C: ld   a,($6A90) // load $6A90 into A
4D6F: and  a       // clear carry flag
4D70: jr   z,$4D77    // if zero, skip ahead to 4D77, else continue

4D72: dec  a        // decrement A to 0
4D73: ld   ($6A90),a // load 0 into $6A90 so it will continue to springboard routine on the next frame
4D76: ret // return to main program

Springboard code:

4D77: ld   a,$01      // load 01 into A
4D79: ld   ($6A90),a // load 01 into $6A90 so it will skip this routine on the next frame
4D7C: ld   a,($6010) // load control input into A
4D7F: ld   e,$01 // load 01 into E
4D81: bit  0,a // set zero flag if NOT moving right
4D83: jr   nz,$4D8D // jump ahead to 4D8D if moving right
4D85: ld   e,$FF // load FF into E
4D87: bit  1,a // set zero flag if NOT moving left
4D89: jr   nz,$4D8D // jump ahead to 4D8D if moving left
4D8B: ld   e,$00 // load 00 into E (joystick is centered)


4D8D: ld   a,($6203) // load Juniors X position into A
4D90: add  a,e // add E to Juniors X positon
4D91: ld   ($6203),a // update Juniors X position (this will move him 1 pixel in the direction the joystick is being held)
4D94: ld   a,$01      // load 01 into A
4D96: ld   ($620F),a // load 1 into $620F (?? not sure what $620F is.. sprite # ??)
4D99: ld   a,($6A89) // load $6A89 into A ($6A89=0 on the downstroke or at the bottom, 1 on the upstroke)
4D9C: and  a // clear carry flag, set zero flag if on the downstroke
4D9D: ld   a,($6667) // load $6667 into A ($6667 =spring position. 50=fully extended..53=fully compressed. 0 if Junior is not on spring)
4DA0: jr   nz,$4DF6  // jump ahead to 4DF6 if on the upstroke

4DA2: cp   $53 // compare spring postion to 53
4DA4: jr   z,$4DB1 // jump to 4DB1 if fully compressed

4DA6: inc  a // increment spring position
4DA7: ld   ($6667),a // update spring position
4DAA: ld   b,a // load spring position into B
4DAB: ld   c,$00 // load 00 into C
4DAD: ld   a,$00 // load 00 into A
4DAF: jr   $4DBA // jump to 4DBA


Arrive here from 4DA4 if spring fully compressed:

4DB1: dec  a // decrement A
4DB2: ld   ($6667),a // load into spring position
4DB5: ld   b,a // load spring position into B
4DB6: ld   c,$04 // load 04 into C
4DB8: ld   a,$01 // load 01 into A

Arrive here from 4DAF if spring not fully compressed:

4DBA: ld   ($6A89),a // load 00 into $6A89 (spring on downstroke)
4DBD: ld   a,b // load spring position into A
4DBE: and  $03 // AND A with 03
4DC0: or   c // OR A with C
4DC1: ld   e,a // load A into E
4DC2: ld   d,$00 // load 00 into D
4DC4: ld   hl,$4E19 // load $4E19 (start address of data table) into HL
4DC7: add  hl,de // add offset to start address
4DC8: ld   b,(hl) // load data from table into B
4DC9: ld   a,($6205) // load Juniors Y position into A
4DCC: add  a,b // add offset
4DCD: ld   ($6205),a // load back into Junior's Y position
4DD0: ld   ($694F),a // update left sprite position
4DD3: ld   ($6957),a // update right sprite position
4DD6: ld   a,($6A87) // load $6A87 into A
4DD9: and  a // clear carry flag
4DDA: ret  nz // return if not zero

4DDB: ld   a,($6010) // springboard check for jump button. Jump button will set bit 7

4DDE: rlca            //rotate left. if bit 7 set then carry flag will be set
4DDF: ret  nc        // if no superjump, return

4DE0: ld   a,($6667) // load spring position into A
4DE3: ld   ($6A8A),a // load A into $6A8A (superjump successful)
4DE6: ld   a,$01 // load 01 into A
4DE8: ld   ($6A87),a // load A into $6A87
4DEB: ld   a,($6A89) // load $6A89 into A
4DEE: and  a // clear carry flag
4DEF: ret  nz // return if on upstroke

4DF0: ld   a,$53 // load 53 into A
4DF2: ld   ($6A8A),a // load 53 into $6A8A
4DF5: ret // return


Arrive here from 4DA0 when on the upstroke:

4DF6: cp   $50 // compare A to 50
4DF8: jr   nz,$4DB1 // jump to 4DB1 if spring not fully extended
4DFA: ld   a,($6A8A) // load $6A8A into A
4DFD: and  a // clear carry flag, check for zero
4DFE: jr   nz,$4E05 // jump to 4E05 if not zero
4E00: ld   a,$54 // load 54 into A
4E02: ld   ($6A8A),a // load 54 into $6A8A (clear superjump indicator)

4E05: xor  a // A=0
4E06: ld   ($6A8B),a // load 0 into $6A8B..(Junior no longer on spring)
4E09: ld   ($6398),a // load 0 into $6398
4E0C: ld   a,($6A9F) // load $6A9F into A
4E0F: ld   ($6010),a // load A into $6010
4E12: xor  a // A=0
4E13: ld   ($6A9F),a // load A into $6A9F
4E16: jp   $1B6E // jump to 1B6E


data table:

4E19: 00           
4E1A: 02           
4E1B: 03           
4E1C: 03           
4E1D: FB           
4E1E: FB           
4E1F: FD
4E20: 00



[marinomitch13]

I'm having trouble following the logic of the programming. So what does this say about the springboard in terms of the range of when you can get a successful super jump? Is it every-other frame for 10 total frames like you thought?

[JCHarrist]

I'm having trouble following the logic of the programming. So what does this say about the springboard in terms of the range of when you can get a successful super jump? Is it every-other frame for 10 total frames like you thought?

Yes, the spring position goes 50,51,52,53,52,51,50. If the jump button is pressed on the first frame of position 51,52 or 53 either on the way down or back up, the superjump will activate.

[marky_d]

So am I understanding this right? There are 5 positions (chances) with alternating frames of jump/no jump when the button is pressed, therefore explaining button mashing's success rate?

[JCHarrist]

So am I understanding this right? There are 5 positions (chances) with alternating frames of jump/no jump when the button is pressed, therefore explaining button mashing's success rate?

Yes, here's how the spring position relates to the 10 frames.

Green circle = superjump if button pressed. Red X = no superjump.

[marinomitch13]

So, we can label the frames like this:

1 Good
2 Bad
3 Good
4 Bad
5 Good
6 Bad
7 Good
8 Bad
9 Good

Even if your first press lands on frame 2, then you probably still have good chances to land on frames 5, 7, or 9 (frame 3 is too close to be practical)! The odds of landing on frame 2 rather than 1 or 3 are probably close to 50%, and the odds of still not getting the super jump after initially landing on frame 2 are probably themselves close to 40% (frames 5-9), so a rough estimation of not getting the super jump in this case would be close to 20%. So about an 80% success rate seems realistic, considering the average mashing speed of players. For those that mash faster, it may be the case that you actually can get 3 attempts in during the allotted time even if you land on frame 2 first, which would give your last mash something close to 50% and result in more like a 90% success rate overall.

[up2ng]

Here's my code breakdown for the superjump. I don't guarantee that all of this is 100% accurate but I'm confident that the routine that polls the jump button and updates Junior's position while on the spring was intended to run every other frame.

JC, Excellent job on the code translation for this section of DKJR!  However, once again, I believe strongly that you are jumping to conclusions.  I don't think that we can say from the code that is shown here that examining the jump button was INTENDED to run every other frame.  In my opinion, that aspect of the code is a bug.

I believe strongly that there was some reason why the programmers decided to skip frames during this section of code.  One possibility was that they are simply trying to run too many instructions for the processor to execute every frame when combined with everything else that it's trying to do on each frame.  But, I don't think that's it. . .  What I DO strongly suspect here is that the programmers were concentrating heavily on the ANIMATION of both the springboard itself and of Junior's position throughout this process and at some point they felt that the animation would be better if the sprites were updating themselves every other frame.  Once this was decided, instead of using some sort of counter that would keep track of whether or not you were on the first or second frame and then running the entire rest of this block of code as normal, but updating the sprites and object positions only every other frame, they decided instead that the best way to handle this would be to simply check this counter up front and then RETURN out of this code block on the inbetween frames, COMPLETELY FORGETTING that they still need to be checking the JUMP button EVERY frame!

Just bad programming.  Again, there were very easy ways that this could have been written properly, but instead they lumped in checking the jump button into the same routine as updating the sprite animation and then they were skipping the entire routine every other frame -- which in my opinion is most likely a bug.

Then, they tested it, it worked once or twice and they said "Great!  Done.  What's next. . .  OMG, when is this game being released again?  There's SO much more to do. . ."

Programming error not caught.  BAM, broken springboard.

[marinomitch13]

Then, they tested it, it worked once or twice and they said "Great!  Done.

Wouldn't it actually be a matter of them testing it and if it always caused the superjump when the jump button was pressed while Junior was on the spring, then they'd know it was probably working? You don't think they'd be able to tell if they didn't mis-time the jump and still didn't get the super jump?

If they thought it would always work, then they'd likely only press once. If they only pressed once, what are the odds that during their testing that every time they attempted the springboard and thought they had timed it right that they'd happen to get a superjump?

[marky_d]

I am wondering that if it was an unintended bug that made the game more difficult why they didn't correct it when they released the easier romset. Since they were jacking with the code anyways it would seem like a great opportunity to fix it to make the game easier.

[marinomitch13]

I am wondering that if it was an unintended bug that made the game more difficult why they didn't correct it when they released the easier romset. Since they were jacking with the code anyways it would seem like a great opportunity to fix it to make the game easier.

Oh, so unlike in DK where they were actually making the game harder by removing the ladder cheat and adding in mid-air steering, with DKjr they actually made it easier?

[marky_d]

I am wondering that if it was an unintended bug that made the game more difficult why they didn't correct it when they released the easier romset. Since they were jacking with the code anyways it would seem like a great opportunity to fix it to make the game easier.

Oh, so unlike in DK where they were actually making the game harder by removing the ladder cheat and adding in mid-air steering, with DKjr they actually made it easier?

Well there were two revisions (that I know of), an "easy" and "hard". Easy is available on mame, and Chris has the unmamed harder revision but hasn't dumped the roms.