I’ve been checking various low-level systems for my my C64 RPG, one being the text system. It’s been through a few changes since I started the project, so here’s the latest.
When I started the project, I added a tokenised text system for compressing text, thinking I’d be using this for a lot of game text packed into one 12K file.
But upon adding my script system, I realised I could embed text into script files, it took a lot of pressure off the compressed text system. So much so, the original 12K of RAM I had set aside first dropped to 8K, then to under 4K.
Recently I ran a test, seeing how much memory the compressed text system was saving me, and the result was ~500 bytes. Hmm… not that much considering all the effort put into it.
Some of the text wasn’t even being used (messages that had since been duplicated into a few script files), and other lines could be embedded into various scripts. After a quick tidy, it brought the difference down to ~400 bytes. And when I checked my engine code, I realised that by not using any compressed text, I could remove all the text decompression code, plus all the associated message printing code. So after a quick bit of pruning, I removed ~400 bytes from my engine code.
Okay, back where I started in terms of RAM use. Compressed text saved 400 bytes, but used up another 400 bytes for the code. No prizes for what I decided to do. Bye, bye compressed text system…
The other advantage of not using the compressed text system was speed. You see, my 2nd text system is what I call “Fast Text”. Fast text isn’t anything special, just ascii turned into C64 screen codes. I have an assembler directive (ftext) to do this conversion work for me, so at run-time I can simply copy the text data directly to the screen.
It also occurred to me that the remaining resident text data can be divided into separate parts; text is used for item descriptions and is only ever needed by the Status Screen. So my next step will be to on-demand load the text once the Status screen is opened.
Lastly, with the resident text file coming down in size, I’ll be able to embed the whole block of text into the game code, thus allowing the game code to grow upwards in memory without having to work around a “rogue” 4K chunk of reserved RAM. Right now I have my game code loaded at $3000 (engine code below this), with an 8K music/SFX buffer at $6000, and the awkward 4K text file at $8000. The new system would instead put the music buffer at $3000, allowing the game code (plus embedded text) to grow from $5000, all the way up to a limit of $9FFF.