3rd time lucky?

After going to bed last night I realised the fundamental flaw in my thinking for the previous two algorithms. Interestingly it explains why my first attempt was closer to the mark and, in fact, essentially borrows from both of my previous algorithms. I'm pretty confident now that I've got it right.

The other encouraging realisation is that there shouldn't be anywhere near the amount of priority shuffling that my last attempt required. To some extent that aspect of it will be dependent on the rendering algorithm used in Knight Lore itself which, understandably, is optimised for its own purposes rather than mine. But the proof will be, as they say, in the pudding.

I should get a chance at lunchtime today to implement my latest theory...

UPDATE: I'm feeling pretty disappointed atm because, with the failure of my latest algorithm, I've all-but-concluded that it's simply not possible to re-order the sprite priority based on only what Knight Lore produces for each frame.

The issue is that I need to maintain a Z-order amongst every object in the room, whilst Knight Lore is essentially only interested in maintaining Z-order information for objects that require re-rendering each frame. It's complicated to explain in a few sentences in a rambling blog, but when a sprite changes its priority - eg. you walk in front of a block - there's insufficient information generated to enable me to determine where in the sprite priority list that sprite needs to move to and, more importantly, with respect to which sprites do I need to preserve the priority.

As an experiment I patched Knight Lore to re-render the entire room each frame and, not surprisingly, each frame was subsequently rendered correctly. It was quite slow, though I should note that I hadn't adjusted the main delay loop value, nor attempted to optimise the re-rendering. So I haven't lost all hope; worst case I may be able to optimise enough of the code to have it playable on the Neo Geo's 12MHz 68K.

But first I'm going to revisit the Knight Lore rendering routine. With the amount of pondering I've done over this issue, plus experimentation, I'm hoping I'll understand more of the algorithm itself, and perhaps there will be a way to impart more of the required information down to the rendering routines. For example, grouping the list by sprites that depend upon one-another may be sufficient to avoid re-render the entire room each frame. Time will tell.

It's disappointing because although it has been fun, I've put a lot of effort into this port and the game - with the .data segment issue fixed - will be 99% there, and it looks and plays quite nicely. It would be such a shame not to have it working properly. It's also trivial to add, for example, the CPC two-tone graphics by simply producing a 2nd set of tiles and tweaking the palette. A soft dipswitch option for the graphics would be a no-brainer.

Fingers crossed!