More progress, certainly, but at the same time, nothing new to see.
The technical detour began with the text rendering. This was already working at character level in PyGame format, but preparing a buffer for printing strings on the ZX Spectrum side led me to realise that memory management in general needed attention. Not all of the 48k of memory is equal, with the first 16k running slower because it's also serving the video generation chip.
The result is that, aside from 6.75k video memory fixed at the start, my memory management code now considers three sections. Firstly, there is 1.25k of slow memory, which only becomes available once the game has finished loading. In the middle, there is 8k of slow memory then 31k of fast memory, with no particular assignment before compilation. Finally, there is 1k of fast memory, which is used for the interrupt table and other fixed lookup tables.
The work happens in the middle section, by reading the required objects from a configuration file, then working out how to best arrange them. One object is the string buffer, which is flagged for inclusion in the fast memory area, because it will be accessed fairly often. Another object is the global variables table, which is instead flagged for alignment to a 256 byte boundary, because that simplifies calculating the address of each variable.
The memory management code is nothing special, but handy for seeing exactly how much memory is in use, and it will save a lot of manual tweaking once space inevitably becomes tight. Continuing the investing theme, I also spent two days automating some configuration file business, which boiled down to three lines of code. I'm still learning.
That's probably my first proper flowchart since school. However, my earlier square boxes approach was good enough for untangling the trickiest knots at the highest level of the virtual machine, which is now a source of contentment rather than vague concern. I am at peace with object-oriented programming, at least until the next time I discover how little I actually know.
I also ended up writing a 3,000 word design document, which was mostly technical but does feed back into some creative decisions. For example, I have settled on block-based movement partly for ease of implementation, partly because it saves a little memory here and there, but mostly because if I can't make a fun game on that basis, then smoother movement won't save me.
Without revealing too much detail before a working implementation, the game will run at 12.5 frames per second. More importantly, at a consistent 12.5 frames per second, aside from an equally consistent pause when changing screens. I won't know for sure while writing the virtual machine, because the only way I can exactly correlate it to ZX Spectrum timings is to write all the ZX Spectrum code first, but I do already have a native screen copy routine (that you might remember from last year), which is the most speed-critical part. The design document also pins down 6.7k of off-screen buffers, in which I need to prepare as much as possible before racing the beam.
The paper exercise has also been useful in revealing that, though the render will stretch my knowledge, pathfinding is practically uncharted territory. Reassuringly, when I checked my notes against an excellent resource for such matters, I found that I wasn't on entirely the wrong track. However, the game could grind to a halt - figuratively and literally - if I get it wrong.
I'll stop there on the technical side, because although I'm only halfway through my notes, this feels like explaining the dead-ends before I reach the answers. Creatively, the ideas keep coming much faster than the programming skills, but I was troubled that I could easily lose the Digitiser feel in moving from cutscenes to an actual game. As if on cue, Chris "Super Page 58" Bell piped up, so now I have a muse-in-reserve who not only knows Digitiser better than Mr Biffo, but also doesn't flinch at these half-formed brain dumps.
My ambition for the next entry has been scaled back to having something new on screen, due to non-game matters scheduled for the next two months. Some are crushingly dull, but Blocktober 2020 is not. Join us, for a celebration of technology so old, it's useful again.
Email: comments at arbitraryfiles.com