Not surprisingly, given the time of year I haven't had much time in the last week or so to work on this project.
That said, I've managed to make a little headway. I've been focused on getting the remainder of the unknown variables (bit flags) decoded and am happy to say that only a handful of bits from a single byte in the object table remains.
The object table contains 3 bytes of flags/counters; the first mostly defined in hard-coded object data and partially documented on the Icemark Knight Lore Data Format site. The 2nd I've now fully decoded, and comprises a counter in the top nibble and flags in the bottom nibble. The 3rd I've partially decoded, but the byte itself is used for different purposes for each of the objects. For some objects it's a counter, others it denotes direction, and others again different bits for different flags. At last count I still have at least 7 uses of flags to decode. I do have clues for 3 of those (all related), which incidentally appear to be consistent for all objects. So that leaves around 4.
For those of you wondering how I have reverse-engineered (and ported) pretty much the entire code base, yet don't understand the purpose of a handful of flags - in most instances the flags are tested and routines simply conditionally exited prematurely, sometimes on the basis of multiple criteria. So it's not always clear what individual flags mean, until you've examined all uses of a flag together. And in some cases, I just haven't gotten around to doing exactly that just yet.
I know of one bug in my C port that occurs in some cases when you pick up a special item, though it is admittedly difficult to play the trickier screens without proper Z-order. For this reason, and the relative lack of bugs, I've concluded that once all bit flags are decoded, there's no escaping attacking the Z-order algorithm. Only then will I be able to properly play-test the game.
It may surprise some of you that I'd never- and I mean never - played the game when I started this port. In fact, even now I've played this far longer on my C port than on any ZX Spectrum emulator. I was so impressed by the praise this game received in Retro Gamer magazines, the screenshots I saw in the same, and the YouTube video I watched briefly, that I didn't need to play the game. In fact, I actually didn't want to; I wanted to experience it for the first time on my own port. It will certainly be the case for the first game I finally play all the way through and win.
Anyway, time will continue to be fleeting in the short term and so I'll hack away at the remainder of the flags and then when the silly season winds down I'll tackle the Z-order algorithm, then hopefully spend most of my time playing the game in order to eliminate the last niggly bugs from my port.
That might be a few weeks off yet as I'll be heading up the coast for a week in the new year and have resolved to leave the laptop at home, the idea being to spend my time after the kids are in bed watching the cricket, reading books on my tablet and if I absolutely must, conversing with my wife. ;)
And I've been thinking about prospective ports again, and the TRS-80 Model 4 is always in the back of my mind. I only just realised in the last day or so that, aside from keyboard input which is trivial, I really only need to re-code two rather straightforward routines to get it running on the Model 4. This is because all rendering is done on a screen buffer in normal memory, with just two blit routines that transfer it to the actual screen. Now I'm sure it'll run into bandwidth issues on the TRS-80's Grafyx Solution hires board, and it may perhaps not been particularly playable because of the slow-down, but at least it'll run and it will look damn impressive - unquestionably worth the exercise given the relatively trivial effort required. It'll probably be my first port after the PC since I've effectively got fully relocatable Z80 source code now.
No comments:
Post a Comment