It is currently Mon Oct 16, 2017 3:21 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Sat Apr 11, 2015 5:36 pm 
Offline

Joined: Tue Aug 27, 2013 3:12 pm
Posts: 10
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.

_________________
Christopher Hopkins - http://www.christopherjhopkins.com
Guest Lecturer, North American Conference on Video Game Music 2015


Top
 Profile  
 
PostPosted: Sat Apr 11, 2015 6:02 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19081
Location: NE Indiana, USA (NTSC)
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).


Top
 Profile  
 
PostPosted: Sat Apr 11, 2015 8:01 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10045
Location: Rio de Janeiro - Brazil
snazzyhoppy wrote:
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).

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

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

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

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

Quote:
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).

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

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


Top
 Profile  
 
PostPosted: Sat Apr 11, 2015 11:44 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
tokumaru wrote:
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.

tokumaru wrote:
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


Top
 Profile  
 
PostPosted: Sun Apr 12, 2015 12:38 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2961
Location: Tampere, Finland
Sik wrote:
tokumaru wrote:
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)

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group