Briley Witch RPG Diary – 09/05/2018

Someone suggested I wrote a blog post about my thoughts on cartridge vs disk, so here we go…

Cartridge vs Disk

My C64 RPG originally started life as a disk game, which caused me a few issues, namely trying to cram everything into RAM. At first I had hoped just to load a few files when needed, using small loaded script files when needed to save RAM. But having the game constantly stop to load data wasn’t ideal.

What I needed was something better…

Someone suggested I took a look at cartridges, so I did.

Well, from what I remembered of my old days, cartridges were either 8k or 16k ROMs, okay for simple little games, but not for my RPG. But after a bit of research, I discovered there were cartridges much larger, as big as 512k! Well, that seemed much better! A standard C64 disk has around 170k capacity, so to say I was a bit giddy about a 512k cart is an understatement.

I think back in the day I had moved from the C64 to the Amiga so somehow missed the console version of the C64 with its large sized cartridges, because I honestly don’t remember them.

Anyway, not only did VICE support cartridges, but certain flash cartridges for real C64s could emulate the cartridge images. I felt bad for those who had expressed an interest in having a disk version of my game, but I decided the benefits of cartridge were too good to ignore, and it would solve most of my problems with storage and speed. Besides, this is my fun little project, so I can do it all my way, right?

But I had to change the whole game to work off cartridge. Plus, there was the problem with the ROM being banked into the memory map 8k at a time…

My solution was to treat the cartridge like a file system, complete with a directory structure. I could use an index to access the files, and use PUCrunch to compress the data, decompressing the file into RAM when required. It didn’t take long to alter my build system to work with cartridges; files are packed into 8k ROM banks in an efficient manner, building a directory at the end of ROM bank 0.

I had used compressed files for the disk version, but loading from cart is so much faster. So much so, it meant my on-demand sprite system could work…

Sprite Management

Originally, my sprite management system was non-existent; I simply loaded various sprite files into RAM, juggling some of the files and loading odd files here and there when needed by cutscenes.

Not an ideal situation, and made worse when I needed to add more character sprites. And when I started to get file clashing, I had not only wrong sprites being used, but some characters were restricted to certain areas. I have parts in the game where a girl named Roana and a boy named Tristan join the party, and was contemplating blocking them from entering the forest sections with Briley due to their RAM being shared by the creature sprites needed for combat…

So I stopped to write a proper sprite management system.

The system is an on-demand loader, made possible by the speed of the cartridge ROM. Instead of loading smaller sprite files, I now have my sprites packed into ROM files containing no more than 124 sprites. This fits nicely under the 8K ROM bank limit. Unlike other data files, these files are stored uncompressed, so to access the data, all I need to do is select the ROM bank, and access the data directly.

So now, to use sprites, I call a subroutine passing in both the ROM file to use, and the sprite ID within that file. The subroutine passes back an index into the sprite cache, which is the sprite frame for the hardware to use.

The system uses a 2k sprite cache, and when a sprite is requested, the cache is first searched. If found, the cache ID is quickly returned. If not, a new sprite needs to be added.

All sprites in the cache have an age associated with them, and age the longer they exist in the cache. But if a sprite is accessed, its age is reset to 0 to keep it fresh.

When a new sprite is needed, the cache is searched for the oldest sprite and that is overwritten with the new data copied from the ROM.

Using this system, I now have no worries about running out of RAM for sprites. I’ve converted all the cutscenes and conversations to use the new format and it’s working wonderful. CPU usage has increased slightly as a result, but I’m using a bit of CPU management so that I now have enough CPU time. Sprites are only fetched when they are needed, so this is seen as a momentary blip on my raster timings. When I have characters animating every 4 or 8 frames, this becomes very infrequent, and once the frames are cached, it’s very fast indeed.

So, with everything now sorted sprite-wise, I’m looking forward to finishing the game.

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