3 - 3 = 3?

Back on home soil, adjusted to the timezone and found a little time to continue with Knight Lore. The immediate task is to (completely) debug the code before adding any more.

The good news is that I've fixed three (3) bugs thus far.

One was interesting; the moon freezing on Day 02 for a minute or more turned out to be from a source I would never have guessed. The game has three (what I call) "seeds" used for randomising certain elements of the game, each having a different distribution. Seed #2 is simply incremented each time through the game loop, and drives the sun/moon moving across the frame.

Although the seed is only ever used (read) as an 8-bit value, the code does a 16-bit increment. On a Z80, that means the lower address - the one read using an 8-bit read - is incremented every loop. On the 6809 however, it's the higher address that is incremented every loop (and the lower address every 256 loops of course). My fault for translating that verbatim without analysing the consequences; a trap for young players!

Once fixed, that in turn revealed another bug where I'd transcribed an AND operation to an INC operation - a simple typo that was, thankfully, immediately discovered. So the sun/moon now continues smoothly throughout the 40 days and nights.

The third bug was due to the fact that I made no attempt to port the original sprite rendering routines, but rather attempted to write (more) efficient 6809 code. No point going into too much detail here, but the original code ends up adjusting the sprite width for non-byte aligned renderings, whereas my code has no need to do so. The problem is that the adjusted value is (also) used later in the code for wiping and blitting - so I had to store the adjusted value but use the original width within the rendering routine itself.

So given that I estimated there were 3 bugs to fix, that only leaves 3-3, err, 3 more by my reckoning. The auto-adjust near the arches still isn't working properly, there's still some (albeit much less) extraneous pixels appearing at the edges of sprites (I believe this is actually corruption of the sprite data, possibly during the flipping operation), and the sprite wiping appears to wipe larger areas than required, leaving occasional gaps in the background. Given today's efforts, it wouldn't surprise me if a couple more surface before I'm done.

That said, this really is the core of the game engine and once it's fully debugged the home stretch is relatively straightforward and any bugs that I add along the way should, for the most part, be immediately apparent.

I was going to release a pre-alpha demo shortly, comprising a much cut-down version with simple objects but no special objects or pick-up and/or drop, but I've decided now to instead press ahead in an attempt to have the game all-but-finished for demonstration (only) on cartridge at CocoFEST. It may lack some polish such as title screen and/or sound, but hopefully it'll be otherwise complete. This of course depends on me getting it finished in time, and also lining up the requisite hardware (programmable cartridge) and someone to show it off for me.

UPDATE: And another bug; jumping off the top of the screen has disastrous effects.

UPDATE #2: I've fixed another 2 bugs - and still have 3 left! Fixed the issue of auto-adjust on the arches, only to notice another issue when in the vicinity of arches. Fixed that, and now exiting screens is a little easier and appears to behave the same as the original.

UPDATE #3: Commenting out the sprite flip code eliminates all the extraneous pixels!

UPDATE #4: Found the bug causing both glitches and wipe issues! Almost perfect now!