Level compression refers to techniques that allow fitting more level data into a smaller space. Levels may easily reach several kilobytes of space uncompressed, and with the cartridge size constraints of an NES game, this is most likely unacceptable. These are some general techniques for NES-friendly level compression, and it is often possible to use multiple ones in the same game.
- 1 Object based
- 2 Reducing the grid size
- 3 Compressed tilemaps
- 4 Other techniques
- 5 External links
Object compression represents levels as a series of commands that represent individual elements of the level. Each "Object" generally consists of an object type, an X and Y position within the level, and a width and a height, where some of these may be implied by the type of object.
Mario series games tend to use the object level compression technique. There are many ways to go about storing the information for objects. Super Mario Bros 1 in particular (and the homebrew game Double Action Blaster Guys) store a "Length" within the object type, where a given range of values refer to the same object at different sizes. This tends to lead to a format like the following:
nttttttt xxxxyyyy |||||||| ||||++++- Y position within a screen |||||||| ++++----- X position within a screen |+++++++---------- Object type +----------------- Next screen flag, moves to encoding the next screen if 1
In this scheme, an object's width or height may be the bottom 3 or 4 bits of the Object Type, and some objects that do not need a size (doors, question mark blocks containing powerups) do not need a length.
For later games, widths and heights are usually given their own dedicated bits. A typical Super Mario World object looks like the following:
nBByyyyy bbbbxxxx hhhhwwww |||||||| |||||||| ||||++++- Width |||||||| |||||||| ++++----- Height |||||||| ||||++++---------- X position within a screen |++|||||-++++-------------- Object type | +++++------------------- Y position within a screen +-------------------------- Next screen flag, moves to encoding the next screen if 1
Super Mario World dedicates another bit to the level's Y position, as non-vertical levels are two screens tall.
Alternatives to next-screen bit
While Mario games typically use "Next screen" bits in their objects, there are ways around it that free up another bit per-object to be used for another purpose, such as the object type.
Each level in President contains a list of how many bytes of information each screen contains, with the engine knowing to move to the next screen once the end is reached. This also makes it easier to move backwards through the level data, by allowing the game to easily get to the previous screen's information.
Nova the Squirrel makes X positions relative, with each object moving forward 0 to 15 metatiles before performing the command.
Games that don't scroll (like single-screen arcade games with multiple levels) also have no use for a next-screen bit.
For objects that only need an X and Y position and no size information (such as coins), a group of them can be stored with only one byte per object, like so:
rxxxyyyy ||||++++- Y position (0-15), absolute |+++----- X position (0-7), relative to the previous object +-------- Repeat; if 1, this command is followed by another of this type
The "repeat" bit could be replaced with another X or Y bit, but that would require a byte to be used up for the length of the group.
With the level effectively made up of a series of commands, it is easy to include signals in the level format that do things other than encode level tiles alongside the actual level objects. For example, Super Mario Bros 1 has a set of commands (encoded as objects with high Y positions) that set pointers for pipe destinations and enable various backgrounds.
Reducing the grid size
One technique for reducing the amount of space the level takes up is to reduce the width and/or height of the level grid that needs to be stored. This is accomplished by making the chunks that the level is composed of larger, so that one byte encodes more space.
In this scheme, the game stores a list of predefined columns of blocks. Through this method, the level is reduced down to a one dimensional array.
The Legend of Zelda is one game that stores its map data as a series of vertical columns. Super Mario Bros 1 has a library of vertical column "templates" that it can then place other blocks on top of.
Vertical columns may not provide the flexibility needed for games, so another option is to make the level out of chunks that have a width as well as a height. If the level is composed of 32x32 tiles rather than 16x16 ones, the game only needs to store 25% as much information, plus the dictionary to turn larger metatiles into smaller ones.
Mega Man games and the Game Boy Pokémon games are examples of games that split their maps into 32x32 metametatiles (megatiles?), composed of four 16x16 metatiles. Blaster Master goes even further, using 64x64 chunks that are then composed of 32x32 metametatiles, that are then in turn composed of 16x16 metatiles. Sonic the Hedgehog 2 uses 128x128 metatiles composed of 16x16 metatiles. Another benefit of 32x32 metametatiles in games that don't scroll vertically is that this is the same size that an attribute table byte covers, so you can store premade color information that is ready to be copied directly into the attribute table.
Another option for level compression is to just start with the final, complete map of the level and use compression algorithms such as run-length encoding, or more advanced options like the LZ77 family.
Kirby's Adventure's levels are stored this way. This method allows complete flexibility with placing metatiles completely freely, but might not compress as well as other methods.
Some types of compression can benefit from storing the level flipped or rotated, and then fixing it before play. For example, for compression based around horizontal runs, a level with many vertical lines could be stored rotated to change the vertical lines into horizontal ones.
Having one row go left-to-right, then having the next row go right-to-left, alternating back and forth. Improves compression on areas of the same tile that touch the edge of the map, allowing the data to be encoded with less runs.
Super Mario Bros has a set of backgrounds that get placed onto each screen before tiles get placed on top of it. With the repeating backgrounds, the game can have a background without needing to specify where each cloud or other element goes.
Nova the Squirrel runs a filter over the level after it has been decompressed, adding edges and corners to ground tiles and performing other changes, such as adding the bottom parts of doors and other objects, or extending things to the ground.
Haunted: Halloween '85 and its sequel The Curse of Possum Hollow use vertical RLE modified with a Markov chain algorithm, which interprets a "run" as a mapping from each tile to the most common tile below it.