Knight Lore (title) make its Coco3 debut

I still need to give the disassembly a once-over and play-test the C version but I thought I'd get started on a few new things just to keep me interested.

Here's the title screen as displayed on the CoCo3; it uses the original spectrum video and attribute memory dump data, first displaying it in monochrome and then colourising it. Just a quick 'n' dirty hack and the palette could do with some improvement.

Title screen - displayed on the Coco3 (MESS)

The other thing I did was take a look at the disassembly of Alien 8, the next game to use the same engine. It looks very, very similar and I don't think it will be a lot of work to reverse-engineer that as well. I've already defined all the code and data spaces.

I wanted to take a look at Alien 8 before getting too far into the Coco3 port because by all reports the engine was improved in some areas, and there's a chance I might be able to incorporate those improvements into Knight Lore (as well).

Not sure yet when I will start on the Coco3 port of Knight Lore proper, but I still have a few things to do with the source and Z80 version first.

I also have some ambitious (and exciting?) plans for the engine on the Coco3 - but that's quite a long while off yet!

Knight Lore disassembly released

I've released RC1 of the ZX Spectrum disassembly listing on the Project List page (see frame to the right), or directly  here.

I still need to give it a once-over and I'll probably add more comments/descriptions.

Next release will be the Z80 source (.ASM) file.

C implementation of Knight Lore complete!

As the new year kicks into gear it has been difficult to find much time to work on Knight Lore. Whilst I admit the subtleties of the Z-order algorithm continue to elude me, I have managed to port it to C and have what is now a complete, if not fully debugged, C implementation.

No Z-ordering implemented

Z-ordering fully implemented

 

I decided that implementing the algorithm in C would only assist in my understanding of it; and it was definitely true to an extent. Whilst the algorithm is somewhat recursive, ultimately the entire scene is re-processed from the start each time a sprite is ordered and rendered.

 

Surprisingly I managed to implement the algorithm itself correctly pretty much on the initial attempt. However, a few graphics glitches remained and hunting them down has taken longer than the above-mentioned implementation. Two of those glitches were the result not of bugs per se, but rather code that I hadn't yet implemented. Most difficult to track down - I implemented the sprite flip routines quite early on in the piece (as they are used on the main menu screen) and had at the time neglected to flip the sprite mask data as I wasn't using it.

Whilst strictly speaking there's no need for me to understand the Z-order algorithm in any more detail than I do right now for the purposes of reverse-engineering or porting the game, it's gnawing at me. I won't release the source until I understand it fully.

That aside, my next tasks are to give the Z80 listing a final once-over before releasing it and spend a bit more time play-testing the port, ideally completing a game or two. It really will be the first time I'll actually sit down and play through the game just for the sake of playing it.

I've been thinking more about the Neo Geo port and I still haven't convinced myself that it's possible. Then again, the rendering may simply involve a completely different approach as there's no need to wipe and draw, but rather simply (re)assign sprites in the correct priority order. I'm sure I can get something running though as I went through a similar exercise with Lode Runner.

Of course the Amiga port beckons and I'll probably tackle that sooner rather than later as I've yet to develop anything through to completion on the Amiga. It really shouldn't take much effort now that I've laid the groundwork.

I'm also thinking of releasing a somewhat cryptic teaser for the Coco3 port...

Getting some ZZZ's... makes my brain hurt?!?

Back to the grind this week and I've started to analyse the Z-order routine in detail. My brain definitely doesn't work like it used to; it's a painstakingly slow progress. Doesn't help that I only get fleeting sessions late at night to work on it. That said, I've had some 'ah hah' moments whilst lying in bed thinking about it too!

There are 27 cases differentiated of two objects and their relative positions; 7 of those result in recursion (causing other objects to be rendered first), another one (where the 2 objects actually intersect) does something for special objects only, and the rest result in the former object being rendered next. I understand the cases but not the groupings at this point...

Double the fun

No reports of performance on real hardware yet, but certainly fun on an emulator.

Just for kicks I decided to rip the on-the-fly pixel-double code from my aborted TRS-80 Apple II Lode Runner project and insert it into Knight Lore. Some two (2) minutes later I had a full-screen Knight Lore running!

Pixel-doubled - in theory 512x192 full screen

For some reason the emulator appears to be sizing the window for 640x240 resolution, but on the real hardware it should be full-screen.

I've added the doubled .CMD file to the zip archive available for download on the Project List page.

I'm interested to know how it performs on real hardware, because there are a number of optimisations for the TRS-80 that could speed it up quite a bit, both in the original ZX Spectrum code and the quick 'n' dirty code I have added for the TRS-80. As soon as I have commented the Z-order algorithm routine I'll release the ZX Spectrum disassembly and my fully relocatable .ASM file that currently builds for both ZX Spectrum and TRS-80.

Knight Lore on the TRS-80

This is the result of, quite literally, 5 minutes coding. And it really did work first build!

The update_screen() function implemented on the TRS-80

This is the update_screen() routine, used to display the main menu and the screen after entering a new room. Here-on after, the code calls a blit() routine to update small rectangular areas of the screen. I expect that won't be a lot more work either, but right now my daughter is sitting on my lap wanting me to print another Nemo picture to colour in...

UPDATE: added the blit routine, and rudimentary keyboard input to allow me to play the game.

Looks better than my C port with proper Z-order

 It's quite playable on the emulator.  There's one glitch in the blit routine that causes certain frames to appear as white rectangles, but I'm sure I'll work that out before too long.

The really amazing thing is that I've spent about an hour on this this morning, starting with stock ZX Spectrum code. So back in the day, it would have taken the Stamper brothers about a day to produce a TRS-80 version; if the hires graphics hardware had the bandwidth to handle it.

UPDATE#2: the game is running perfectly (under emulation) on the TRS-80.

The glitches were caused by a clash between Knight Lore and the TRS-80 memory map. Knight Lore builds ~4K of look-up tables for bit-shift and bit-reverse in high memory ($F000) for the rendering routines. I simply moved them down low and the game now runs properly; I still had a couple of minor relocation issues to sort. I also coded the proper keyboard logic to support all keys supported on the Spectrum. In theory the TRS-80 port is complete now.

The game appears to run roughly the same speed as the Spectrum under emulation. The TRS-80 CPU clock (4MHz) is slightly faster than the ZX Spectrum (3.5MHz) but the graphics are likely slower.

For academic interest I'll build a pixel-doubled version next, though it'll run even slower on real hardware of course.

Location. Location. Location.

I can't ignore the lure of a quick port to the TRS-80 now that I realise how trivial it will be.

For Lode Runner I used a simple build script for the Coco3 port; this time I've opted for a makefile. The Z80 port will support ZX Spectrum, TRS-80 and possibly MSX2.

The Knight Lore .ASM file is now fully relocatable (yes, I've tried) and obviously I can build the ZX Spectrum version. Next will be the TRS-80. The TRS-80 Model 4 has two (2) hires video modes; 512x192 and 640x240. Using the former, Knight Lore (256x192) will occupy exactly half the screen. That'll be my first pass effort, then I'll produce a pixel-doubled version to fill the screen. I suspect they'll run fine under emulation where there's no contention with the CPU - the real hardware will be a different matter. I'd be especially interested to see how Ian Mavric's improved clone will perform!

Next post should have some eye candy!