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.

Chipping away slowly

Still progressing, even if slowly, each time I open up the disassembly to look at it.

I mentioned in a previous post a 'related' project; I'll talk about it more now since I had a closer look at it today.

The project involved modifying a ZX Spectrum emulator specifically for this game in order to render the screen using the OpenGL library on a modern platform - pretty interesting idea! Tonight I decided to read up on the technical details of the project - written in Spanish - and learned a thing or two about it. There's even information on the game in there that contradicts what I've read on another site, and I suspect that when I've digested it fully it may actually clear up some confusion I've had thus far in certain areas.

Technical details aside, the rendering algorithm looks a lot simpler and cleaner in C code. Unfortunately at this point, sections of it don't appear to bear any resemblance whatsoever to the original Z80 code; at least I can't find the corresponding implementation. To further obfuscate matters, the code - comments, variables and functions - is written entirely in Spanish. Early days yet, however.

Regardless, I have a feeling that I'm not too far off a breakthrough and although there's a fair amount of code to implement in C before I can render all of the game's screens, at the same time I'm also pretty confident that it will only take a small amount of code to render one specific location.

Jumping the gun

Further analysis of the code reveals a very different story to that I painted last post. I am, in fact, quite a way off from being able to render a screen accurately. Indeed, the amount of code I need to reverse-engineer before being able to render came as quite a shock! I assumed that most of the remaining code was to handle special objects and AI; however every object to be rendered calls into a jump table that calls common routines at least 2 layers deep, and all are rife with magic numbers.

I'm sure though, that I only have to understand a handful of them before the rest of them simply fall into place. And that is what I attempted to do tonight, with moderate success. Still, I've only just scratched the surface.

The up side is that once I can render a screen, there's not much of the game left to reverse-engineer. Underneath the impressive graphics, the game mechanic is deceptively simple; something later games in the series built upon with an enhanced engine.

One other thing I now understand; there is a utility available that supposedly lets you dissect the game's graphics and data structures, allowing you to study sprites, objects, room contents, and the entire map - the ultimate idea being that you could update or create your own game within the confines of the existing data structures. The only thing is, the menu option to render the room doesn't actually do anything!

Well that's because you have to reverse-engineer pretty much the entire game to actually render a single room and notably, the game disassembly available on the same site covers around 5-10% of the game code. No doubt I'm not the first one to be taken by surprise!

However, I do hope to go one better than the author of the above-mentioned utility!

UPDATE: The author of said utility has responded to my email claiming it was mere laziness that prevented him from finishing his utility! I suspect the truth of the matter - evidenced by the (lack of) information available on the site - is that he either had no idea what lay ahead, or more likely was put off by the effort required (most of the original reverse-engineering effort was done by someone else).

Next post: The reveal?

It's been a slow day today so I took the opportunity at lunchtime to work on the project.

I finished coding the routines that build the display list for the screen rendering and for a quick test, simply added a call to the rendering routine for each sprite in the list. The result; not surprisingly the sprite positioning needs adjustments but the display is encouragingly similar to what I would expect to see!

So obviously now I'll be reverse-engineering the rendering logic in minute detail and updating my C source as I progress. The next milestone is to have the screen rendering 100% accurately. Then I can finally post a screenshot and no doubt reveal the identity of the game!

At the risk of giving it away now, this game has seen a few ports (some home-brew) and a few remakes on more modern platforms. Despite that, and also occasional claims of having reverse-engineered the game, I can't find more than what I would describe as a preliminary attempt at a disassembly anywhere on the net. I don't like to re-invent the wheel where avoidable, but in this case I can't help feeling I'm actually doing just that. Regardless, I've put a fair amount of effort into this and it only makes sense to complete it myself now.

Having said all that, I did only just today find a rather unique project from 2006 that I will describe in a later post for fear of giving too much away.

As I've alluded to in previous posts, I've got some ambitious plans for this port, particularly where the Coco3 is concerned. I'm quite excited to see where I can take it, but I've still got many more months of work before I can even kick it off.

Getting ready to render!

A few more hours tonight on the port. Good progress.

The focus was on the dynamic data structures; how they are built, what their relationships are, and how they are used. As a result I've updated the disassembly with more accurate and descriptive labels and comments, including some of the work done by others that preceded me.

The good news is that I now understand most of what is required to render a screen. The game builds a table of (simple) sprites to be rendered; the first 2 are the player, the next 2 are special objects, and the remaining (up to 36) comprise background, then foreground sprites. I'll go into more detail in another post.

The bad news is that each sprite has a pre-render routine that fiddles bits and bytes in the sprite rendering table, and at this point I don't know what half the bytes in the table do. That said, I haven't even attempted to reverse-engineer them just yet.

Next session I'll complete the coding of the data structure building in C, and then start on the actual rendering just to see what falls out without the per-sprite data fiddling. I don't think it'll be long before I have something that vaguely resembles a proper screen!

All play and no work...

Fast approaching the end of the work trip and I've only just managed to find the time and muster the inclination to work on the ZX Spectrum port tonight. Between jet lag, dinners out, Skyping the family, watching Alaska-based reality TV on Discovery Channel and other distractions, I haven't quite achieved as much as I'd forecast on the project.

That said, the C implementation is shaping up nicely. Tonight involved importing data, and defining & initialising the object-related data structures that are used in the main rendering logic. Rewriting it in C definitely assists in understanding the relationships between the various data structures.

As I've mentioned previously, the output of this process should be a fully-rendered screen and a significant portion of the core game engine (reverse-engineering) complete. Another hint: there were a couple of games that followed this one, both updating the engine in the process. I would imagine that it wouldn't be too difficult to port these to the Coco3 once I've finished this one.

I've just discovered that Retro Gamer magazine did a feature on this game some time back. Just downloading a digital edition now so I can have a read before I fall asleep tonight.

Only 2 more nights here, and at least one of those is ear-marked for dinner, so I probably won't get a lot more done before returning home.