 |
| Now with added sprites - albeit in the wrong location |
You will, no doubt, notice that the sprites are not in the right location - more about that later...
But first, after hooking up the palette to the sprites, I discovered that the bitplanes were reversed in the Donkey Kong sprite ROM's w.r.t. the tilemap ROM's... something that may simply be a 'bug' in MAME as the ROM's are organised in the driver arbitrarily to some extent. Either way, a simple fix to my conversion tool and I was up-and-running with correct colours just a minute or so later.
In the process I fixed a bug (which was disabled anyway) in my tilemap rendering routine and did a few minor optimisations. I'm still not convinced that a complete rendering of both tilemap and sprites every VBLANK is going to cut it on the final version, but gee it'd be nice - very nice - if it did!
So, about those sprite locations; stepping back a bit the whole X-Y issue has been somewhat clouded from the beginning, given that the display on the Donkey Kong cabinet is rotated 90 degrees. I've referred to coordinates as 'X' & 'Y' and also referred to 'rows' and 'columns' throughout my commented disassembly and, to be honest, I'm not sure I haven't been inconsistent in some areas. And whilst it's easier to think about Mario's X coordinate changing as he runs across a girder, it is in fact his sprite's Y coordinate that is changing in the hardware. And of course, a row of text spanning multiple columns is actually a single column of text on the display spanning multiple rows. So what convention do you choose, and how do you make it clear? My brain started hurting right about now.
So when mapping all this to the Neo Geo hardware, it complicates the issue. And to make matters (much) worse - at least where sprites are concerned - it's not a nice 0-N range on one/both axes on either hardware platform! The sprite rendering code in MAME, for example, looks like a veritable dog's breakfast, somehow involving the current scan line! Arrggh! And of course, supporting both orientations means I have to solve the problem twice. If my brain was hurting before, it's throbbing now!
As a result, thus far I've managed to place the sprites somewhere on the screen for now.
To be honest, I haven't decided my plan of attack from here (sprite coordinate issues aside). I'll have to take some time to study the uncommented areas of code to work out how best to proceed. Ideally, it'd be nice to get Mario running and climbing, without the distractions/complications of timers, barrels and fireballs, and possibly easier to understand the sprite coordinate issues. Having said that, I have no idea at this stage what proportion of the remaining code would need to be ported to achieve that.
To give some very vague idea of what I've done so far, the PDF listing from IDA is approximately 80 pages of code. But that can be rather verbose with comment lines between functions, and added lines for cross-references - let's say 20%, so maybe 60 pages of Z80 code. My main.68k file, which contains (mostly) non-Neo Geo specific code, is currently 8 pages of code. However, operations can be done rather more efficiently in 68K code, so I'm going to estimate that would represent at least 10 pages of Z80 code. Using these very rough figures, I might say that I've ported about 1/6th or 17% of the code; doesn't sound like much when you put it like that. But there is an awful lot of 'grunt work' code remaining - code that will simply be a matter of turning the handle. Tedious but straighforward.
No comments:
Post a Comment