A8 Donkey Kong Jr. Arcade HACK

[Tempest]

Also, I am not sure what I might be able to do with Donkey Kong's profile. Might not bother, but I'm pretty sure I won't be able to resist.

 

He looks 'alright' as is, but maybe make him a little more 'spread out' instead of standing so straight and upright.

[tep392]

Fantastic work so far! It looks 1000x better!

[+darryl1970]

Fantastic work so far! It looks 1000x better!

Thanks!

[tep392]

Is it me, or does it seem way to easy to fall of the edges of the platforms?

[+Cafeman]

I didn't realize how easy it is to DIE in this version. I can't even beat stage 2.

 

On Atari800win, the yellows and greens are only slightly different in hue. The greens look better in the screenshot above than on my PC. But the tweaked colors do make it look noticeably nicer. I haven't played the original to compare against yet.

[+darryl1970]

I didn't realize how easy it is to DIE in this version. I can't even beat stage 2.

 

On Atari800win, the yellows and greens are only slightly different in hue. The greens look better in the screenshot above than on my PC. But the tweaked colors do make it look noticeably nicer. I haven't played the original to compare against yet.

That is one of the flaws with this version. The control is very touchy, and it's easy to run off of a platform. Jr. takes pretty big steps, and the collision could be tweaked some.

I got this game on cart when it was released. I adapted quickly back then. Picking it up years later, I realized how touchy it can be. I am adjusted again, but it's touchy!

Once you figure out the quirks, it gets easier.

 

Is it me, or does it seem way to easy to fall of the edges of the platforms?

It is not you. lol. That could be tweaked a little! Not my specialty area though.

[+Cafeman]

Is the game checking which tile Jr is standing on? Or does it have an x,y map of walkable places?

[tep392]

It would be nice if it was a map. Then we could go in and tweak the boundary's. I'll do a little tracing in the debugger and see if I can figure it out.

[+playsoft]

In case it helps, here is the source which builds the xex before Darryl runs a program to put his graphics into it.

 

The original character set and sprite data contained in the program is compressed. That data is still in there, I just put hooks in to write over the data after it has been decoded. The other hook I have is in the DLI in order to change that colour.

 

The disassembly is only complete to the extent that it identifies code and data. I make sure any hook leaves the footprint the same and does not change any addresses.

 

If you do end up making changes to this I will need to search out the colour locations again - the program Darryl has to adjust the colours writes to specific locations in the xex file.

 

Good luck!

 

Paul

xex.zip

[+Cafeman]

I am a real greenhorn when it comes to tracing through a disassembly. Since you guys were able to change the dying animation, is it too hard to find where it is triggered , then maybe you could locate where the checks for platform walking / falling-death collision are.

[+playsoft]

First clue - it's something to do with the data written to $1036. On the first screen break and edit $1036 to $F0... that seems to extend the bottom left pad to the entire width of the screen.

[+Cafeman]

I changed address $1036 from orig value $5A to $6A and got this.

 

address $1037 is the right-bounds of the 2nd platform. I added $10 to it and saw the same extending effect.

address $1038 is the right-bounds of the 3rd platform.

But extending $1037 seems to cause Jr to not be able to stand on 'top' of the subsequent platforms, he is stuck down on the horizontal row of the 2nd platform when he jumps and lands. Interesting.

 

So maybe if you added +$2 to each number, you'd slip off a lot less. I haven't found the Left-Bounds yet.

 

EDIT - $101B starts the left-bounds for the platform. Thus, change memory address $101c from 6c to 5c - and the 2nd platform left bounds gets greatly extended. So if you subtracted $02 from each of these, you'd slip off a lot less.

 

EDIT2 - $1041 is the lower left first pad on stage 3 (springboard stage). I changed $1041 from 56 to 66 .. result: I was walkin' on air on the right-bounds. So it looks like this area is all 2 arrays of left-bounds and right-bounds and you just have to figure out which values apply to each stages' various platforms. If you want to tweak that.

 

[tep392]

We should locate the values in the source file. The boundry values get copied from $A75F. It looks like there are a number of tables that get copied into RAM. Probably separate tables for each screen. Here are were the pointers used to copy the data get set. This is called with X=3 for the setting up the 1st screen. Start tracing at $B3A1 to see how it's done.

 

;set pointers for data to be copied to RAM
LB8A1: lda LB8BC,X
sta ABUFPT+2
lda LB8C9,X
sta ABUFPT+3
lda LB8D6,X
sta ICHIDZ
lda LB8E3,X
sta ICDNOZ
ldy LB8F0,X
lda LB8FA,X
rts
;pointers to source data
;lsb
LB8BC: .byte $00,$48,$D8,$5F,$00,$F8,$FE,$2E
.byte $2E,$BE,$DD,$67,$51
;msb
LB8C9: .byte $20,$27,$27,$A7,$24,$28,$1A,$1D
.byte $1D,$1E,$BB,$AB,$B4
;pointers to destination in ram
;lsb
LB8D6: .byte $00,$00,$00,$00,$00,$78,$6E,$7E
.byte $BE,$0E,$00,$00,$AE
;msb
LB8E3: .byte $30,$31,$31,$10,$34,$29,$1E,$1D
.byte $1E,$1F,$08,$20,$1A
;number of bytes to copy
LB8F0: .byte $07,$01,$01,$08,$02,$7F,$4F,$4F
.byte $4F,$2F
;
LB8FA: .byte $80,$00,$00,$00,$00

 

I'm sure there is some kind of structure in the data that defines the number of platforms and their x,y boundaries.

[+Cafeman]

To me, it appeared the RAM table area in $1000+ was the same values in Stage 1 and Stage 3. Not rebuilt with a new table for each screen. FYI.

 

In other words, all the boundry and other tables are built at game-start, and each stage uses its own preset portion of those tables.

[+therealbountybob]

Is it me, or does it seem way to easy to fall of the edges of the platforms?

I fond it safer if you keep your legs together before jumping (on the first and springy screens), you get used to it. However it does play well as it is

[+darryl1970]

Exciting finds. Does this mean it's mapped? I thought maybe he steps too many pixels at a time,to make the math line up. Plus, the snap jaws do have to move 8 pixels at a time.

 

I'd also like the red snap jaws to reverse at the true bottom of the vine. If Jr is at the very bottom of the vine, shouldn't get him.

[tep392]

I located the platform data in the code. The platform height is measured from the top of the screen. Smaller numbers are higher.

 

example: lower left platform on 1st screen is located at y=$c9, left=$3e, right=$5a

;$A75F
;platform height
;1st screen
.byte $C9,$BA,$C2,$BA,$B2,$92,$62,$42,$3A,$21
;3rd screen
.byte $C9,$BA,$C4,$BA,$C3,$BA,$A2,$9A,$9A,$3A,$3A,$21
;4th screen
.byte $CD,$C2,$9A,$72,$42

 

;left boundry
;1st screen
.byte $3E,$6C,$80,$90,$A4,$61,$55,$8D,$6B,$5F
;3rd screen
.byte $43,$43,$5D,$6F,$8C,$A4,$78,$43,$95,$99,$6B,$5F
;4th screen
.byte $40,$56,$57,$57,$6A

;right boundry
;1st screen
.byte $5A,$7A,$8A,$9E,$B1,$68,$60,$9D,$88,$64
;3rd screen
.byte $B2,$56,$67,$81,$9C,$B2,$82,$55,$A2,$9E,$8C,$64
;4th screen
.byte $4F,$9E,$9E,$9E,$9E

[+Cafeman]

Hey, that's good work there. Now, the question is, does Darryl1970 / Playsoft agree that the game could use a few tweaks along the left/right boundaries?

 

It would make the game a bit easier since you wouldn't fall off quite so much. But we all quickly learn to deal with the "slippery edges" by staying in the middle more anyway, so its not as necessary a tweak as the 5200 Popeye step-climbing and bottle-punching corrections. but still, since we have it the data values now, I'm all for making it a pixel or two less likely for Jr to fall into the water!

 

I always enjoyed this port (also Donkey Kong on A8). These nips & tucks which make interesting improvements to the ROM's are SO FRIGGIN COOL!

[+therealbountybob]

These game explorations are fantastic reading and very useful

 

If the falling off when jumping issue was to be improved, would it not be a matter of tweaking the jump code timing rather than redesigning the layouts - he seems to fall off too quickly? Perhaps his legs can go back together when you stop moving and reposition him slightly so he is centrally on the platform segment, though this wouldn't help when you were doing a running jump.

 

Can someone clarify about the screen building and the collisions:

 

With only 4 screens I would have guessed the level data was hard coded, but they are built by item, or a combination of both? For Ramp Rage I loaded the playfield/scenery data, then built the game items (targets, ramps etc) based on marker bytes to create tables of addresses.

 

If the screens and items are all built / table based, I guess that opens the game up to having some new levels?

 

In Ramp Rage I detected collisions in game, as I did in Gwobby Strikes Back!. Here in DKJr does the game use the boundaries table to see if he is able to move, climb etc or fall off, so it's not checking the screen data as such?

 

Thanks

[+playsoft]

tep392, on 12 Dec 2015 - 03:51 AM, said:

I located the platform data in the code. The platform height is measured from the top of the screen. Smaller numbers are higher.

 

 

I plotted those out for the first level (and think I have done it reasonably accurately):

 

 

They are compared against the top left of Jr, so you can see how he will fall once more than half of him is over the edge.

 

Interesting that one platform is not covered at all and that others are only partially covered - perhaps something to do with where jumping is possible.

[+playsoft]

And this is what 3 and 4 look like:

 

 

 

 

 

 

 

 

[tep392]

You can't actually walk on the far right platform, so it has no boundry defined. If you lower yourself to it on the vine, you don't go into standing/walking mode. The boundry only applies to a platform that you are standing on. I've noticed some interesting things. If I extend a platform so I can reach a vine that normally can't be reached from that platform, I'm not allowed to jump to it and climb. Also, if I extend the bottom left platform across the screen, I can walk to the pedestals on the right but I can't jump onto them. I can only jump on to them from one of the adjacent pedestals. If I try to drop onto an extended platform from a vine, I fall through it and die. It seems there are several layers of logic that control where you can walk/jump/climb.

[+darryl1970]

These are great finds! I never imagined this would take off like this. What a great, fun, and talented community to be a part of!

[tep392]

Also note that the position of player's 0 and 1 (left half of JR) are used in the boundry computations. This is why the boundry limits are offset to the left. On an NTSC screen, the boundry's are offset upwards by 16 scan lines.

[tep392]

 

others are only partially covered - perhaps something to do with where jumping is possible.

My guess is that the platform at y=$92 is only partially covered because there are vines on the left side, so he can't walk off that side. The vine logic takes over.