Help with a map system

[Tsutarja]

This one is related to another side project (aside the arcade type shooter that I'm making).

How do I make a map system that:
-Specific collision/function data is assigned to specific tiles
-Map consists of "screens" which are build out of metatiles

The only problem is that I don't know how to create metatiles and collision data (because there is no metatile tutorial anywhere). Once I learn this, I think I can figure out the rest.

[tokumaru]

Metatiles have been discussed to death in these forums, I'm sure you can find something nearly as good as a tutorial if you look around. The basic idea behind metatiles is that they're an extra layer that sits between the game code and the name/attribute tables. When rendering maps to the screen, instead of reading tile indices from PRG-ROM and writing them to VRAM, you read metatile indices, which you use to look tiles up in a set of tables so you can send those to VRAM. The specifics can surely be found in past threads, with lots of source code examples.

As for collisions, metatiles often have collision data attached to them as well, in addition to tile and palette information. Often a single byte can indicate the type of the metatile, such as ground, air, water, hazard, and so on. In order for characters to collide with the background you have to check a few key points around them against the level map, and take action depending on the types of the blocks the characters are touching. This has also been discussed a lot, I'm sure you can find some useful info if you look.

Sorry if my answer is a little vague, it's just that these are 2 of the most complex aspects of making a game (the other ones being scrolling and A.I.), so it would be hard to summarize everything about them in a single easy to follow post. Like I said, there are plenty of past threads on these subjects, so you really should take a look at them fist and come back here with more specific questions about things you didn't understand.

[DoNotWant]

http://www.nintendoage.com/forum/messag ... adid=33287

For meta-tiles, check the "Background Compression" tutorial.

[Tsutarja]

I've been thinking about a map system for a while now and I want to know if this is a good way of doing it:
-8x8 tiles form metatiles
-metatiles form screens
-screens form stages

I haven't figured out a good way of decompressing the map data yet, but this feel like a good way of compressing it.

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)?

[tokumaru]

-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.

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.

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.

[tepples]

To put it in perspective, Sonic the Hedgehog 3 levels are about 12,000 to 20,000 pixels wide and 3,000 to 4,000 pixels tall, if the maps at this page are half scale as I assume.

[Tsutarja]

I guess I have to put this project (which I mentioned in the first post) on hold for some time because trying to make two games at the same time is too much for me. But I guess it's not bad idea to learn stuff beforehand you feel like are going to give you trouble when you get there. Thanks for the help anyway