Monday, 30 November 2015

And the name of the game is...

A few more sessions and I've managed to reverse-engineer and implement enough to render the first room which, incidentally, contains no foreground objects. If this screen shot isn't enough to give the game away, then you need to hand back your Retro Gamer T-shirt.

A seminal title for the ZX Spectrum
At this point I'm obviously not concerned with colour. Technically the bitmaps are all monochrome and the game sets the attribute (ink) for different areas on the screen. Besides, not unlike Lode Runner, the game is perfectly playable in monochrome as is evident from the BBC Micro port.

Recent developments include identification and partial commenting of the recursive sprite/object priority-encoder algorithm (which I've yet to port) and - quite obviously - the 3D-to-2D translation and rendering routine.

For reasons not readily apparent to me, each of the game's sprites has a routine that tweaks the display coordinates; some are hard-coded and some depend on other factors. Why at least the hard-coded values weren't implicit in the sprite data is beyond me...

Next step is to render a room with foreground objects, which are handled differently to the background objects since multiples of which can appear anywhere in the room, and can also move around. However I believe I've already reverse-engineered most of that logic already. Like the background objects, it'll be a matter of implementing all the per-sprite tweaks that will take most of the time.

Still a few holes in my understanding of the data structures and variables but it's all coming together and I feel I'm heading towards the home stretch; less analysis and more handle-cranking - which isn't a bad thing. I still find the idea of a 6809 port a little daunting, but it's also a good chance to hone my 6809 coding skillz.


  1. Not having any ZX-Spectrum experience, I may have to turn in my retro gaming card. However, Google helped me find the game so I'm going to hang on to the card on a technicality.

    Those Rare guys are pretty damn good coders (see arcade Killer Instinct's MIPS software blit as one example). Thus I'd expect their code has good reasons to work in a certain way.

  2. It's puzzling that a bunch of sprites have hard-coded display offsets; try as I might I can't come up with a reason why that would be a good idea knowing what I know about the game. Having said that, there's still stuff I don't know yet...

    I'm starting to wonder whether this might actually work on the Grafyx Solution - albeit with flicker without a double-buffer - and it would of course be much easier to port to another Z80 machine.