When not to compress stuff.

[Ian A]

Okay, so I've been reading up a lot about level compression and now have this question:

Is there anything specific that you leave out of your compressed level format? For example, to me it makes sense to store your objects (enemies, items, etc) separate from your nametable data, but what about tile attributes such as collision data (solid, nonsolid, ice)?

Also, while I'm here, I was thinking about storing palette information with my 32x32 metatiles, but would it be better to combine it with other tile attributes (solid, etc) and put it with 16x16 metatiles instead?

[MottZilla]

I definitely wouldn't recommend leaving out collision/physics data from being compressed in some way. Storing large arrays of collision data in ROM would be a waste. You might want to store collision data for each 32x32 block or 16x16 block, whichever you find suits you best as there isn't just 1 correct answer. Storing Attribute data in your 32x32 blocks makes sense as each attribute table byte represents that much space and could make your updating of the attribute table less complicated. Although you could do it for smaller areas by saving a copy of the attribute table in RAM somewhere as I remember some people suggesting.

[tepples]

If you represent your game's world as a grid of metatiles, then ideally, surface characteristics such as slope, solidity, and slipperiness should be attached to the metatiles, not the map. For example, the map might say "ice blocks here", and then you'd look up the friction for "ice block" in a table.

Which way are you scrolling? There are fairly efficient ways to build an attribute update buffer depending on this, even for 16x16 pixel metatiles.

[tokumaru]

Is there anything specific that you leave out of your compressed level format? For example, to me it makes sense to store your objects (enemies, items, etc) separate from your nametable data, but what about tile attributes such as collision data (solid, nonsolid, ice)?

I thing this depends a lot on the project, and specially on how much RAM and ROM you have. If you have a lot of RAM (like 8KB of it in the cart) it makes sense to have nearly everything compressed, as you can just decompress the data to this memory and use it from there. But if you don't have a lot of RAM you'll most likely have to leave some things uncompressed or compressed with a scheme that allows for random access (not the case of LZ or RLE, for example).

Also, while I'm here, I was thinking about storing palette information with my 32x32 metatiles, but would it be better to combine it with other tile attributes (solid, etc) and put it with 16x16 metatiles instead?

I have my palette information in the 16x16 metatiles, but that's only because I have small objects that overwrite the background which need that kind of precision, but if it weren't for these objects it sure would be easier to have all the palette info be part of the 32x32 metatiles.

[Ian A]

Which way are you scrolling? There are fairly efficient ways to build an attribute update buffer depending on this, even for 16x16 pixel metatiles.

I was thinking four way scrolling, but with vertical mirroring.

I thing this depends a lot on the project, and specially on how much RAM and ROM you have. If you have a lot of RAM (like 8KB of it in the cart) it makes sense to have nearly everything compressed, as you can just decompress the data to this memory and use it from there. But if you don't have a lot of RAM you'll most likely have to leave some things uncompressed or compressed with a scheme that allows for random access (not the case of LZ or RLE, for example).

I'm thinking about using MMC1, so I'll probably have quite a bit of both, but I'm worried about maneuvering through the map data with being able to scroll in four directions.

[Celius]

I always have collision information embedded in my 16x16 metatile definitions. However, I do like to have palette information tied to my 32x32 metatiles. That way all I have to do to make levels is place tiles in a grid, and since I'm only specifying which tile goes where, it allows me to free up bits for more tile definitions (so I don't have to sacrifice bits for color/collision information when designing levels). Having the color information with 32x32 metatiles also saves time, as you don't have to do as much bit manipulation as you do with 16x16 metatiles.

[tokumaru]

I was thinking four way scrolling, but with vertical mirroring.

I consider vertical mirroring (unique nametables side by side) the best choice for four way scrolling. Scrolling glitches are less annoying at the top and at the bottom of the screen than at the sides.

I'm thinking about using MMC1, so I'll probably have quite a bit of both, but I'm worried about maneuvering through the map data with being able to scroll in four directions.

IMO, the fact that the nametables are 30 tiles tall kills some of the benefits of assigning attributes to the 32x32 metatiles, because you'll have to do some manipulation on the nibbles depending on the vertical scroll. Since you'll have to do bit manipulation anyway you might just decide to switch to 16x16 attribute precision.

If you want to keep your options open, you should just stick to having all the attributes/properties be part of the 16x16 metatiles. This means you will not be able to take some shortcuts when rendering or reading that data, but it also means that you will not need to rewrite a lot of code or rearrange a lot of data in case you decide to modify something about your rendering and physics engines.

[tepples]

PROTIP: Use the upper 2 bits of the 16x16 pixel metatile number as the attribute number. For example, tile $04 wound be palette 0, $B5 could be palette 2, etc. SMB1 does this, and it saves a table lookup.

[Celius]

PROTIP: Use the upper 2 bits of the 16x16 pixel metatile number as the attribute number. For example, tile $04 wound be palette 0, $B5 could be palette 2, etc. SMB1 does this, and it saves a table lookup.

I was originally going to do this for one of my projects, but the problem is you sacrifice 192 metatile IDs just so you can save a lookup table. I do think this is a great solution if you are using <= 64 16x16 tiles, but for more graphically detailed/complex games where you might use more 16x16 tiles, I think it's better to use a lookup table.

[Ian A]

PROTIP: Use the upper 2 bits of the 16x16 pixel metatile number as the attribute number. For example, tile $04 wound be palette 0, $B5 could be palette 2, etc. SMB1 does this, and it saves a table lookup.

I was originally going to do this for one of my projects, but the problem is you sacrifice 192 metatile IDs just so you can save a lookup table. I do think this is a great solution if you are using <= 64 16x16 tiles, but for more graphically detailed/complex games where you might use more 16x16 tiles, I think it's better to use a lookup table.

Well, I think you'd still have 256 meta tiles, but they'd be in four groups organized by palette. You'd only be able to have 64 for each palette, though. That's assuming I'm understanding this correctly, though.

I've got a bit to think about now, but this helped me sort out a lot of stuff. Thanks!

[tepples]

Use the upper 2 bits of the 16x16 pixel metatile number as the attribute number [like] SMB1

I was originally going to do this for one of my projects, but the problem is you sacrifice 192 metatile IDs just so you can save a lookup table.

Well, I think you'd still have 256 meta tiles, but they'd be in four groups organized by palette. You'd only be able to have 64 for each palette, though. That's assuming I'm understanding this correctly, though.

You understand perfectly. Metatile $41 need not have the same picture or surface information as metatile $01; they can be completely unrelated.

[Celius]

Wow, I never thought about it like that, actually. Still, you're limited in what you can do, and if you have lookup tables where you use the tile ID as an index, you're forced to have it be at least 192 bytes if you want to use the fourth palette. In that case, you might actually save space by having an extra lookup table for attribute information. But of course, you have to look at your end results to see which is more efficient (once you have all your metatiles defined, try both methods and see which one saves you space/time).

[tepples]

Wow, I never thought about it like that, actually. Still, you're limited in what you can do, and if you have lookup tables where you use the tile ID as an index, you're forced to have it be at least 192 bytes if you want to use the fourth palette.

Super Mario Bros. gets around this by splitting a lot of its lookup tables into four parts, but depending on what you're doing with it, that might be another lookup. So the game might use $01-$2F, $40-$56, $80-$A2, etc. This is also how it solves the problem of 1024 bytes being too much for an index register: it only takes 256 bytes for each 64-tile table.