Briley Witch RPG Diary – 17/04/2018

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.

Text System

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.

 

One thought on “Briley Witch RPG Diary – 17/04/2018

  1. We did a text compression competition in the German C64 forum (forum64.de) a couple of years ago. It showed that you can bring down text size to roughly 50% by using a combination of Huffman-Coding and a tokenizer like yours, with a surprisingly small code size. But when you are using many small texts that need to be depackable individually (as for a game), the gain will get much smaller, because both the texts themselves as well as the texts referenced by the tokens most probably need to be byte aligned. All in all probably a lot of effort, with a memory saving that is not overwhelming in the end. Having levels that are a tiny bit smaller is probably a much better idea :-).

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s