Skip to content

Case Study: Compression in Platformer Chant

You are here:
Estimated reading time: 2 min

Some older games have background decompression, but it is extremely tricky to do, especially considering the fact that we are using SGDK and its unpack code is hidden inside the implementation.

Technically, you can load data row by row or do something like that, but it would be an extremely rocky road, trust me. Lots and lots of bugs to be expected, and, of course. slowdowns

Keeping levels in ROM is not an option either, because you’ll quickly get out of free ROM

Here’s what you can do…

Of course, splitting levels into small levels will work, but there are alternatives.

First of all, you should most likely use 16×16 “metatile” block already instead of working with 8×8 tiles and collision map

You should not keep your tileset in RAM at all. The tileset is unpacked -> it is loaded into VDP -> you can discard it, you should only remember its base index in VDP

Second…

In Lethal Wedding, as an example, there are a couple of small levels and a couple of large levels. In this instance, Mikhail the developer has done “partial” compression. Basically, each level is split into large segments, 64×32 8×8 tiles. 

On level load, routine creates a map of those segments in memory and tests if those segments are compressed or not. If the segment is not compressed, it is stored in “metamap” as is, just by copying the pointer. If the segment is compressed, then it is unpacked into the RAM, and the pointer to RAM is used instead. This allows us to compress 24k of ROM this way per each level out of max 64k.

However, this scheme might be tricky to do too, but at least it is not streaming.

You can also do something like this:

  1. You can split your level into FG tileset, BG tileset, FG map, BG map and collision map
  2. Unpack and load FG tileset into VDP, discard it in RAM
  3. Unpack and load BG tileset into VDP, discard it in RAM
  4. Unpack FG map and store it in RAM if it is compressed, otherwise use FG map from ROM

The same for BG

The same for collision map

You should be doing your tiled-to-image converter anyway. You can decide which parts you’ll be compressing and which parts you’ll leave uncompressed.

Say, you allocate a slab of 32K RAM for the levels

You’ll be able to know the size of your BG map/FG map/collision map just by the level size alone. You know the size of each block in bytes = you can calculate ROM usage for each part of this.

And then converter decided whichever it wants to compress and whichever it keeps uncompressed.

Was this article helpful?
Dislike 0
Views: 1
Back To Top