Questions about NES Graphics Limitations
Posted: Thu Dec 19, 2013 9:31 pm
I am not an NES developer. I am, however, developing a game that will imitate the visual aesthetic of the NES. I may opt to ignore some of the system's limitations, but I would like to understand exactly what these limitations are before I choose which ones to ignore.
The system's capabilities as I understand them are as follows:
-Standard resolution of 256 by 240, NTSC resolution of 256 by 224 with the top eight and bottom eight scanlines cropped.
-A built in palette of something like 52 or 54 unique colors. This is not an RGB palette, which means I probably can't use a true NES palette and will likely have to settle for a reasonable facsimile.
-Can use up to four different 3-color palettes for tiles plus four different 3-color palettes for sprites plus one background color at a time.
-Two sets of 256 8x8 tiles in memory at once.
-One scrolling layer.
-Up to 64 sprites at once; up to 8 sprites on a single scanline.
-Sprites are 8x8 or 8x16, globally. 8x16 sprites use consecutive tiles from their tileset. Thus, if an 8x16 sprite only uses one 8x8 tile, the tileset includes a consecutive 8x8 tile that is blank.
-Sprites can be flipped horizontally or vertically. Background tiles cannot.
-Offscreen buffer on only one scrolling axis at a time.
Let me know if I forgot anything important.
As I learned more about the NES and continued to develop the concept of my game, several questions came up concerning the capabilities of the NES. I was hoping somebody here might be able to help me understand it.
1. As I understand it, several of the limitations of the NES, such as color palettes and the single scrolling layer, can be waived on a per-scanline basis. Are there practical limitations on how this can be done? What kind of techniques would actually be viable in a commercial NES game?
2. I don't know what color emphasis is or how it works. What does color emphasis do, and what are the limitations on its use?
3. Can the NES reload tilesets on a per-scanline basis? If a game makes use of a status bar, do the tiles for the status bar have to come from the same tilesets as the terrain and/or sprite? Another example: Suppose I have a game that scrolls quickly between areas when the borders are approached, like Zelda 1. Can I scroll vertically between two areas that use different tilesets? What about horizontally?
4. Sprite flicker actually feels kind of gimmicky to me in a contemporary game, but, hypothetically, let's say I opt to include it. How could I accurately replicate its appearance?
5. I don't plan on including four-direction scrolling in my game, but as a simple point of curiosity, I'm wondering about the graphical implications of scrolling artifacts. This may become relevant if I include oversized boss monsters.
Thanks in advance for any help. Please remember, I'm not developing for the NES itself, so I'm less interested in the functions of the hardware as I am in their implications on the graphics. A lot of the technical aspects are likely to go over my head. I'm interested in how far the system's graphics could be pushed, but I also want to temper this information with an understanding of what techniques are viable in commercial games, as well as which ones were in common use. Feel free to provide example games. Thanks again.
The system's capabilities as I understand them are as follows:
-Standard resolution of 256 by 240, NTSC resolution of 256 by 224 with the top eight and bottom eight scanlines cropped.
-A built in palette of something like 52 or 54 unique colors. This is not an RGB palette, which means I probably can't use a true NES palette and will likely have to settle for a reasonable facsimile.
-Can use up to four different 3-color palettes for tiles plus four different 3-color palettes for sprites plus one background color at a time.
-Two sets of 256 8x8 tiles in memory at once.
-One scrolling layer.
-Up to 64 sprites at once; up to 8 sprites on a single scanline.
-Sprites are 8x8 or 8x16, globally. 8x16 sprites use consecutive tiles from their tileset. Thus, if an 8x16 sprite only uses one 8x8 tile, the tileset includes a consecutive 8x8 tile that is blank.
-Sprites can be flipped horizontally or vertically. Background tiles cannot.
-Offscreen buffer on only one scrolling axis at a time.
Let me know if I forgot anything important.
As I learned more about the NES and continued to develop the concept of my game, several questions came up concerning the capabilities of the NES. I was hoping somebody here might be able to help me understand it.
1. As I understand it, several of the limitations of the NES, such as color palettes and the single scrolling layer, can be waived on a per-scanline basis. Are there practical limitations on how this can be done? What kind of techniques would actually be viable in a commercial NES game?
2. I don't know what color emphasis is or how it works. What does color emphasis do, and what are the limitations on its use?
3. Can the NES reload tilesets on a per-scanline basis? If a game makes use of a status bar, do the tiles for the status bar have to come from the same tilesets as the terrain and/or sprite? Another example: Suppose I have a game that scrolls quickly between areas when the borders are approached, like Zelda 1. Can I scroll vertically between two areas that use different tilesets? What about horizontally?
4. Sprite flicker actually feels kind of gimmicky to me in a contemporary game, but, hypothetically, let's say I opt to include it. How could I accurately replicate its appearance?
5. I don't plan on including four-direction scrolling in my game, but as a simple point of curiosity, I'm wondering about the graphical implications of scrolling artifacts. This may become relevant if I include oversized boss monsters.
Thanks in advance for any help. Please remember, I'm not developing for the NES itself, so I'm less interested in the functions of the hardware as I am in their implications on the graphics. A lot of the technical aspects are likely to go over my head. I'm interested in how far the system's graphics could be pushed, but I also want to temper this information with an understanding of what techniques are viable in commercial games, as well as which ones were in common use. Feel free to provide example games. Thanks again.