Jump to content

An Overview of 8x16 Sprite Mode for the NES


Recommended Posts

NES 8x16 Sprites Overview

Following is a brief summary to using the 8x16 sprite mode offered by the NES. I wrote the bulk of this sometime back in February of 2015 for @KHAN Games to pitch this mode for Isolation. To make this write-up useful for beginners, I have explained some things further for this post. For most people reading here, you can skim over these parts. 🙂

I can thank @Optomon for my understanding of the subject.

So, the NES displays background graphics with 8x8 pixel tiles.
It can display foreground graphics using either 8x8 or 8x16 pixel tiles. These individual tiles are referred to as sprites, and their combination to make larger graphics would be referred to as metasprites.
All tiles for sprites and background accessible for display are stored in two pattern tables, which are viewable through the PPU Viewer menu options of Mesen or FCEUX.

Arranging Graphics with 8x16 Sprites

As you may know, this is the order of tiles as loaded into the pattern table of the PPU:

Standard PPU Tile Arrangement

This does not change when the pattern table is loaded for 8x16 sprites. However, the manner in which the NES displays sprites from the pattern table does. This is the order in which tiles are arranged when pulling 8x16 sprites:

8x16 Tile Arrangement

To cycle between these two views, select the FC/NES x16 setting in yy-chr:

Building Sprites with 8x16 Sprites

To display an 8x16 sprite, the tile ID pulls two adjacent 8x8 tiles and displays them one above the other. (This is why $01 is below $00 in an 8x16 layout.)  Now, since a single sprite tile ID references what would—in 8x8 sprite mode—require two IDs, half of the IDs have seemingly been freed up. What’s the good in that? Now, sprites can be pulled from both pattern tables: the sprite pattern table (00, or left) or the background pattern table (01, or right).

Sprite IDs for Pattern Table 00:

Sprite IDs for Pattern Table 01:

As you can see, tile IDs ending in an even digit, or nibble, such as 0, 2, 4, … A, C, E, etc., pull sprites from the left pattern table (00).

Whereas, tile IDs ending in an odd nibble (1, 3, 5, … B, D, F) pull sprites from the right pattern table (01).

Download the above Tile IDs as a CHR file here. (For better understanding, open this file in yy-chr and view it in both 8x8 and 8x16 viewing mode.)

But What About the Background?

Have no fear, you can still build backgrounds from whichever pattern table you've assigned for background, just as you would have in 8x8 sprite mode. But now you can use the same tiles for either background or sprites. You just have to arrange your background tiles within the pattern table in an accommodating order if you want to use the exact same tile for both.

For Example

If we place the tiles for, let's say, a ceramic pot within the background pattern table…

…we can construct the pot using background tiles like so:

…or construct the very same pot as a sprite, like so:

(The tile IDs shown above assume that pattern table 01 is set as the background table. They would be $04,$06 )

Therefore, the pot as it exists in the pattern table (and as it would be viewed in a PPU viewer):

When are 8x16 sprites useful? 

  • When you want very large sprites (since each tile is twice as tall, larger objects can be defined with less data. You can also cover twice as much screen retail before you hit the 64 sprite limit.)
  • When you have many vertical elements that need to be displayed as sprites (the tiles can’t be rotated though, they're always 8 wide by 16 tall )
  • When you want to reuse graphics as both background and sprites.
  • When you want a larger variety of sprites, and need less background tiles.
  • When you want players to interact with background objects (ex. pick up a pot from a row of pots, you can use the same graphics to make the row of pots with background tiles until the player picks it up, then you can rewrite its area in the nametable (background) with blank tiles and load the same graphics in its place as a sprite for interaction.) This is helpful to get around scanline limits, such as pushing boxes in a Sokobon-like.)

When are they a hindrance?

  • When you have many objects smaller than 8x8, such as bullets. Remember, even the transparent pixels in a tile count toward scanline usage.
  • When you need to rotate vertical objects (ex. an arrow being shot vertically would be perfect for 8x16, but would require more space in the pattern table to be shot horizontally or diagonally than 8x8 mode would.)
  • When your characters’ heights are an odd number of 8x8 tiles. (For example, large Mario is three tiles, or 24 pixels high. It would be a waste of chr space to use a stack of 8x16s to draw him.)
  • When you need to pack as much as you can into your pattern table (in 8x8 mode, a 16x16 character might animate a walk by just changing the bottom half of the tiles. With 8x16 tiles, you would need to duplicate the top half, wasting chr space.

More Info:

For instructions on how to activate 8x16 sprite mode, refer to the PPU OAM page of the NesDev Wiki.

Edited by M-Tee
A little more info, fixed some typos.
  • Like 4
Link to comment
Share on other sites

Another advantage is the amount of sprite real estate that you get. We only get 64 sprites total on NES, without tricks and such (don't ask me about the tricks; I'm not well versed haha). With 8x16 you get the luxury of an effective "128" sprites, even though it is still only 64 sprites, if you get my meaning.

  • Like 1
Link to comment
Share on other sites

I appreciate the credit here, thanks. I remember vaguely explaining this to you. Being able to use the background tile sheet for sprite tiles is a very underrated advantage.

On a side note, it was weird having worked in 8x16 mode for a long time with the CV hacks, then making Rollie in 8x8 (which was an ABSOLUTE necessity, due to the pattern table cramming and recycling of 8x8 tiles).

  • Like 1
Link to comment
Share on other sites

  • Create New...