Tsutarja wrote:
-8x8 tiles form metatiles
-metatiles form screens
-screens form stages
A LOT of games handle map compression like this, so yeah, this is proven to work very well.
Quote:
I haven't figured out a good way of decompressing the map data yet
You do it by processing each compression layer at a time until you reach the final entity (tile). Kinda like this:
1- use level coordinates to find the position of the screen in the level map;
2- read the index of the screen at that position;
3- use this index to form a pointer or as an offset into the table of screen definitions;
4- use level coordinates to find the position of the metatile in the screen;
5- read the index of the metatile at that position;
6- use this index to form a pointer or as an offset into the table of metatile definitions;
7- use the level coordinates to find the position of the tile in the metatile;
8- read the index of the tile at that position;
You can optimize this in different ways depending on how the data is stored and how often you have to perform the steps above. Some unrolling will allow you to read levels compressed like this in real time, without having to decompress them to RAM first, but most people find it easier to decompress larger portions of the level beforehand.
Quote:
Also, would it be a good idea to make a coordinate system that counts pixels, blocks, screens and regions/sectors (only if screens go over 255)?
256 screens would make a level 65536 pixels wide. Even a character as fast as Sonic would need around 3 minutes to run this distance in a straight line (without speed shoes). I don't think you'd ever need a level this big! =)
Anyway, you don't need to have separate coordinates for the different entities that form the level, because you can extract them all from a single set of coordinates with a few bitwise operations, as long as all the entities are sized in powers of 2. Take my word: it's much safer to maintain less state and extract more state from that than to keep track of more state. The more things you have to update in sync, the bigger the chance of screwing something up losing that sync. Redundancy should be avoided whenever possible.
For example, if you use 16x16-pixel metatiles, the 16-bit coordinates can be broken down like this:
16-bit coordinate: ssssssss mmmmtppp
ssssssss: screen within the level (0 to 255);
mmmm: metatile within the screen (0 to 15);
t: tile within the metatile (0 to 1);
ppp: pixel within the tile (0 to 7);
This is the same coordinate you use for physics, collisions, everything, and you can easily extract the coordinates of level entities from it with a bit of bitshifting.