Filling Nametables: Scrolling and Metatiles

[snazzyhoppy]

I am learning about how to compress and decompress screen data. I am confused though about how to store the data in ROM and how to decompress it using RAM. Below are some questions and some statements I want to make sure are accurate:

1.
Can you list an NES game, published or homebrew, and whether it stores screen data in rows, columns, and/or objects? I suspect games load the initial two screens in the two nametables by rows and then use column data to fill the additional screens while scrolling.

2.
As I understand so far, games that are two screens wide can fill nametables one row at a time. So the screen data can be stored as bytes of one row, then the next, etc.

3.
For games that scroll (horizontally for this example), columns are drawn in an area that is not currently visible. So the screen data can be stored as bytes of one column, the next, etc.

4.
I also read somewhere in these forums that there are some games that keep data on the objects in a level and add them to a nametable that is filled with transparent tiles. I think Super Mario Bros. does something like this. Is there an advantage to this over bytes in row or column order?

5.
When storing metatiles, what is a suitable size for a buffer? I understand that if using 2x2 metatiles (each tile being 8x8 pixels), I can fill the nametable with one row or column of the metatile and then place the other two tiles in the buffer. How would the buffer be affected by 4x4 metatiles or larger sizes? For my first project I'm like to stay within NROM, CNROM, and UNROM banks.

Thanks for your help.

[tepples]

1. Super Mario Bros. loads background maps as a stream of objects and decodes them to columns. Operating in columns even for initial loading means you only have to write column-based code, not row-based code.

2-3. Correct

4. Objects can be smaller to store, especially if repeating a single object many times. Space was at a premium in 1985; SMB1 is only 40 kilobytes and was still the biggest Famicom game when released.

5. When decoding metatiles, you can decode the left half in one frame and the right half in the next. This means you need a 12 to 15 byte buffer for the column of metatiles themselves and a 24 to 30 byte buffer for the map data that will actually be written to PPU port $2007 (VRAM data port).

[tokumaru]

I am learning about how to compress and decompress screen data. I am confused though about how to store the data in ROM and how to decompress it using RAM.

There are literally thousands of possibilities. The most appropriate solution for each game depends on the exact game mechanics, the type of scrolling and the memory limitations (how much ROM and RAM is available).

I suspect games load the initial two screens in the two nametables by rows and then use column data to fill the additional screens while scrolling.

A lot of them, yes. In my own programs I don't see the need to completely populate the two name tables in the beginning, I only care about the part that's actually visible (i.e. an area slightly wider than 256 pixels).

Games like SMB3 and Kirby's Adventure don't even arrange the name tables horizontally, but vertically. SMB3 limits the height of the levels to the height of 2 name tables stacked vertically, minus the height of the status bar. So yes, it does update in columns, but it barely has any room where to hide these updates, so color glitches can be seen at the edges of the screen as it scrolls.

There are also games that update columns in less conventional ways. Take a look at Duck Tales, Mega Man or The Little Mermaid (all Capcom games, so they likely used the same system in many of their games) in FCEUX's name table viewer. As the screen scrolls, large 32x32-pixel squares are drawn in columns every few pixels. Looking at name tables is a great way to see how each game handles scrolling.

As I understand so far, games that are two screens wide can fill nametables one row at a time. So the screen data can be stored as bytes of one row, then the next, etc.

If levels are only 2 screens wide, you can use whatever method you'd like, since you don't have to bother about incremental updates. You do have to consider that you also need the collision data for that level, so keeping that easily accessible is important.

For games that scroll (horizontally for this example), columns are drawn in an area that is not currently visible. So the screen data can be stored as bytes of one column, the next, etc.

The actual format in which levels are stored isn't so important as long as you are able to read rows and/or columns from it as necessary. You can still read columns from a level that's stored in rows, you just have to add "LevelWidth" to the pointer, instead of 1, when reading the data. Games that scroll in both axes must be able to read both rows and columns from the same level map.

I also read somewhere in these forums that there are some games that keep data on the objects in a level and add them to a nametable that is filled with transparent tiles. I think Super Mario Bros. does something like this. Is there an advantage to this over bytes in row or column order?

It's more compact, because you don't have to define the contents of every location of the map, just those that actually contain something, and even then, often in a compressed way.

When storing metatiles, what is a suitable size for a buffer? I understand that if using 2x2 metatiles (each tile being 8x8 pixels), I can fill the nametable with one row or column of the metatile and then place the other two tiles in the buffer.

In my engine, I chose not to buffer at all, I update all 4 bytes of every metatile (specially considering that I expect scrolling speeds higher than 8 pixels per frame).

How would the buffer be affected by 4x4 metatiles or larger sizes?

Take a look at the Capcom games I mentioned. Instead of rendering columns of tiles, they render columns of 32x32-pixel metatiles, but it takes several frames until a new column is complete. If you have the space to hide updates from the player (games using 1-screen mirroring don't, and games with 2 name tables and multidirectional scrolling don't in at least 1 axis), Capcom's way has the advantage of not needing a buffer at all, because entire blocks are written each time.

For my first project I'm like to stay within NROM, CNROM, and UNROM banks.

Mappers are not a problem. All mappers can do all types of scrolling, but you have to take into consideration the amount of PRG-ROM you have available for storing levels in order to select an appropriate compression format.

[Sik]

SMB3 limits the height of the levels to the height of 2 name tables stacked vertically, minus the height of the status bar.

Wait, its levels are that short? I thought there were a few that are taller, I swear.

There are also games that update columns in less conventional ways. Take a look at Duck Tales, Mega Man or The Little Mermaid (all Capcom games, so they likely used the same system in many of their games) in FCEUX's name table viewer. As the screen scrolls, large 32x32-pixel squares are drawn in columns every few pixels. Looking at name tables is a great way to see how each game handles scrolling.

It helps that it means that updating the palette would just overwrite the entire relevant byte (no need to preserve bits), and that it reduces ROM usage to 1/4 than it'd be with 16×16 chunks =P

[thefox]

SMB3 limits the height of the levels to the height of 2 name tables stacked vertically, minus the height of the status bar.

Wait, its levels are that short? I thought there were a few that are taller, I swear.

There are a couple that scroll vertically and diagonally, but for the most part what he said is true.

(From: http://vgmaps.com/Atlas/NES)