I want to rewrite my map scrolling code, so I have been thinking about what kind of data format to use for the maps. The old format I used was sort of lazy: 16x16 pixel metatiles in a flat table. This time I'd like to go for something better. If any of you have any thoughts on the topic, please share them.
Some design goals/constraints:
- Should be generic rather than limited. I don't mind losing a little bit in efficiency (in space and time) due to this. No object based formats like used in SMB1.
- Should work with multi-directional scrolling.
- Shouldn't needlessly limit artistic freedom (no "64 metatiles should be enough for everybody").
- Should be able to store a variety of extra info for tiles, such as 1) color attribute 2) slope type 3) collision flags
- Should not depend on extra cartridge RAM (but should be able to work with maps decompressed to WRAM).
There are so many options available I'm having hard time coming up with anything concrete, because I don't have a good grasp on the benefits/drawbacks of things such as:
- Metatile size (32x32 pixels? 16x16 pixels? Metatiles of metatiles?)
- Divide the map to screens of e.g. 256x256 pixels? (This seems like a good idea, so that sparse maps can be supported efficiently by having a map of screens. I guess "screen" here is really nothing but another name for a big metatile of metatiles.)
- Should attribute data be stored in metatiles, or should there be a separate map for them? Same goes for collision data. (Many, many options here. E.g. if we use 32x32 pixel metatiles which consist of 16x16 pixel metatiles, we could store attributes in the either metatile, or separated so that the same metatile could be used in two places with a different palette, for example).
- Maximum number of metatiles? 256 is a natural limitation to use here, but how likely are artists to run out of metatiles, say at the 16x16 pixel metatile level?
Existing solutions in games:
- Blaster Master apparently uses 256x256 pixel metatiles (screens), consisting of 64x64 pixel metatiles, consisting of 32x32 pixel metatiles, consisting of 16x16 pixel metatiles. I may have been misinterpreting the document I found, but it's something similar. The color attribute is associated with the 16x16 metatile.
- Gimmick uses 16x16 pixel metatiles. The whole map is stored more or less as is. The map is divided to screens, but the screens are not used to reduce redundancy. See my earlier post for some more info.
- Kirby uses 16x16 pixel metatiles and 256x192 pixel screens. Maps are stored compressed in ROM and decompressed to WRAM.
- <add your favorite game here>
Thoughts?
EDIT: Added an extra constraint about not requiring WRAM.
Some design goals/constraints:
- Should be generic rather than limited. I don't mind losing a little bit in efficiency (in space and time) due to this. No object based formats like used in SMB1.
- Should work with multi-directional scrolling.
- Shouldn't needlessly limit artistic freedom (no "64 metatiles should be enough for everybody").
- Should be able to store a variety of extra info for tiles, such as 1) color attribute 2) slope type 3) collision flags
- Should not depend on extra cartridge RAM (but should be able to work with maps decompressed to WRAM).
There are so many options available I'm having hard time coming up with anything concrete, because I don't have a good grasp on the benefits/drawbacks of things such as:
- Metatile size (32x32 pixels? 16x16 pixels? Metatiles of metatiles?)
- Divide the map to screens of e.g. 256x256 pixels? (This seems like a good idea, so that sparse maps can be supported efficiently by having a map of screens. I guess "screen" here is really nothing but another name for a big metatile of metatiles.)
- Should attribute data be stored in metatiles, or should there be a separate map for them? Same goes for collision data. (Many, many options here. E.g. if we use 32x32 pixel metatiles which consist of 16x16 pixel metatiles, we could store attributes in the either metatile, or separated so that the same metatile could be used in two places with a different palette, for example).
- Maximum number of metatiles? 256 is a natural limitation to use here, but how likely are artists to run out of metatiles, say at the 16x16 pixel metatile level?
Existing solutions in games:
- Blaster Master apparently uses 256x256 pixel metatiles (screens), consisting of 64x64 pixel metatiles, consisting of 32x32 pixel metatiles, consisting of 16x16 pixel metatiles. I may have been misinterpreting the document I found, but it's something similar. The color attribute is associated with the 16x16 metatile.
- Gimmick uses 16x16 pixel metatiles. The whole map is stored more or less as is. The map is divided to screens, but the screens are not used to reduce redundancy. See my earlier post for some more info.
- Kirby uses 16x16 pixel metatiles and 256x192 pixel screens. Maps are stored compressed in ROM and decompressed to WRAM.
- <add your favorite game here>
Thoughts?
EDIT: Added an extra constraint about not requiring WRAM.