Two-tone graphics

Taking a break from sprite priorities, curiosity got the better of me and I decided to take a look at how easy or otherwise it would be to rip the graphics from the Amstrad CPC version.

Knowing absolutely zero about the platform, and never having even run a CPC emulator before, it was surprisingly easy to get up-and-running and within half an hour I was disassembling the CPC version of Knight lore!

On the surface it looks a lot closer to the MSX version than the ZX Spectrum version. They've also obviously had to optimise it for space; they've eliminated the unused 4 bytes in the graphics object table, and reduced the maximum number of objects.

Early days yet but I've located the sprite data table and I'm a little perplexed. For starters, they've reorganised the order of sprites in the table (no big deal because there's a table of pointers to each sprite which can't be changed). The sprite width is double the ZX Spectrum counterpart, but the number of bytes in the table is the same, except for the addition of 1 extra byte!

I'll need to study the sprite rendering routine in detail to work out what's going on of course. I've also seen a couple of sprites that are 1 or 2 lines shorter/taller than the ZX equivalent. I'm hoping that's simply an optimisation for space, and that the adjustment values in the update routines haven't changed - because that would be a disaster and probably render the exercise not feasible.

Just for some eye candy, this the the CPC version...

Example screen shot I ripped from the net.

UPDATE: With the benefit of a decent night's sleep, it's immediately obvious that the sprite (data) width (in bytes) is twice that of the ZX Spectrum version because there's 2BPP. And the data size is the same because there's no need for a mask (which can actually be thought of as a 2nd colour plane) in this instance.

A little more disassembling this morning reveals that the extra byte follows the width and height specifiers and appears to be 0 in every sprite. The flip_sprite() routine duly ignores this byte, though it remains to be seen if the code writes to it at any point.

A couple of sprite table entries differ in that they (instead) point to the NULL sprite, and there's six (6) additional entries to the sprite table, including graphics for two (2) additional sprites. I'm yet to investigate which they are.

Next task is to analyse the sprite data to determine if it's 100% compatible with the ZX spectrum version. That means comparing the sprites (by eye), the widths and heights and the purpose of the extra sprites. Then I can make a call as to whether it's possible to simply paste the sprite data into the current C port or whether it would require tweaks to the code.