Managed to find some time last night (yes, NYE - I have a toddler who is not sleeping well atm so no parties for me) and at lunchtime today (yes, working on 1st Jan - the fun of owning your own business) to work on Neo Kong.
Last night I finished the climbing, including commenting most of the logic. During level initialisation, the code builds a table of ladder top-and-bottom coordinates, and each frame checks to see if Mario is at either end of a ladder. Not too complicated at all, but it did take some time reverse-engineering and commenting the code. So now Mario can climb to the top of the girder (and other) levels.
As an aside, the code has an anti-tamper routine that checks if the copyright message is in-tact. If not, it corrupts the above-mentioned ladder data so the game won't play properly.
The next thing I tackled was the end-of-level-check routine. That was straight-forward, cranking-the-handle type work and now when you reach the top of the girder level, Kong grabs Pauline and climbs off the top of the screen, and the game progresses to the next level. Different level types have different (albeit similar) 'reunion' sequence logic so the girder level is the only one working for now.
So today I tacked the jumping. This is the first area of the code that I've really struggled to understand how it works. In fact, not too far into it I decided to just forge ahead porting the code. There's a lot of it, and amongst it there's plenty of unknown variables and mathematics that escape my understanding for the moment (no surprise that other listings haven't commented this code either). I've ported most of the code; a few routines left that I believe have to do with grabbing the hammer mid-jump. However, it's not quite working yet...
Mario will jump, in what looks like a decent arc but roughly twice as high as he should, and instead of landing on the girder he continues to fall through the bottom of the screen, and into the top, where the game deems that the level has been completed as Mario is at the 'top'.
Given that there's so much code ported 'blind', as well as a few missing subroutines, I'm not surprised by this at all. It does however mean that I'll need to go back and try to understand what's happening. I suspect it'll take a handful (or more) of hours in the MAME debugger on both the Z80 original and Neo Kong.
Anyway, once jumping is complete I'll upload a new video showing Mario's movements and completion of the 1st level. From there-on in, I'll start on the scoring aspects of gameplay, and inevitably start to implement the barrel and fireball AI.
On a different note, an alternate DK ROM set was sent to the MAMEDEV team in the last few days. This so-called 'hard' set differs from the US set by only a handful of bytes. Given that I'm mid-analysis of DK, I couldn't resist having a look.
It's a patch to a single routine; the 'difficulty timer' routine that calculates enemy object speed from 1-5 during the game. It's based on how long you've been on a screen, plus the current level that you're playing. The patch, which overwrites unused text at the end of the ROM, always sets the speed to 5, except when the speed would normally be '1' on the girder level. So you get a short reprieve on that level, until the speed ticks over to 2, where it's immediately cranked up to 5. It's not known if it's an official patch, but it looks a little 'hacky' to me.
On a last note, after finishing the climbing code I went through the listing tallying up the percentage of code that has been analysed (which is approximately what has been ported) and was a little surprised (and a little disappointed) to learn that it's only around 50% at this point. What that means is that there's still a lot of tedious, low-level game mechanics (AI etc) to work through.
No comments:
Post a Comment