This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

How RLE decompression to be done in a platformer?

How RLE decompression to be done in a platformer?
by on (#63525)
In one of previous posts I read about the simple Run Length Encoding compression and a decompression routine.

How should the RLE be used when it is supposed to decompress the map for a side scroller platform game? I can think of 2 options:

1) Decompress the whole level into memory just before a level is about to begin. Scrolling then will just require to copy from this memory area to the nametable. This option will demand a lot of work RAM.

2) Decompress the level data on the fly. i.e. Decompress the level data onto Name table whenever the need arise. Simple RLE will not help here I guess.

Any other suggestions will be appreciated.

by on (#63529)
1) This method allows the greatest destructibility of the environment, which is why M.C. Kids and SMB3 use it. You usually need an 8 KiB PRG RAM at $6000 to do this. (But see this thread for an alternate solution.)

2) If you store a separate RLE state for each row of metatiles, and you scroll only one way (like SMB1, TMNT2, or TMNT3), you can use horizontal RLE. I have code demonstrating this technique if you want to see it. SMB1 does something similar with its object-based level encoding: An object (or "run") can be multiple rows tall, there can be four objects (one terrain and three others) active over any column, and everything is drawn on top of a plane of clouds and the like.

by on (#63535)
You can pick a better kind of compression if you take into consideration the type of scrolling your game will have. Is your game a side scroller or does it scroll vertically as well? Does it scroll at all?

If it doesn't scroll, things should be really simple, just compress each screen separately and decompress them to a RAM buffer before using. If it scrolls horizontally, you can still make it work by encoding each screen separately, but you'd need RAM buffers for two screens that you'd overwrite as the level scrolled.

Vertical scrolling makes things more complex unless you have the RAM for 4 screen buffers, but that can be too much if you have only 2KB. So you might want to switch to a row-based approached to compression, where the screens would all be composed by a fixed number of rows and only the rows themselves would be RLE-compressed. That would slightly reduce the efficiency of the compression, but would give you random access to individual rows, allowing you to scroll vertically using the same 2 RAM maps as if you scrolled only horizontally.

by on (#63560)
If you use method 1, definitely use a better decompression method.

RLE is very helpful when loading on-the-fly, it's fast and simple to implement.. unless you want to scroll backwards. I guess scrolling back could be doable still, but would make the compressed data larger and more complicated to access (unless someone has a good idea for an 'RLE rewind' hack).