Sprite size

From NESdev Wiki
Revision as of 15:47, 7 September 2013 by Tepples (talk | contribs) (→‎External links: sprite shearing)
Jump to navigationJump to search

The NES PPU offers the choice of 8x8 pixel or 8x16 pixel sprites. Each size has its advantages.

Advantages of 8x8

If the majority of your objects fit in an 8x8 pixel sprite, choose 8x8. These might include tiny bullets, puffs of smoke, or puzzle pieces. Drawing, say, a 4x4 pixel bullet with an 8x16 pixel sprite would waste pattern table space and increase potential for dropout or flicker on adjacent scanlines.

If your game's characters are 21-24 pixels tall, 8x8 pixel sprites may be the best choice. For example, this is true of Mario Bros. (1983), Balloon Fight, the enemies in the original Super Mario Bros., and the hero in the Mega Man series. And in Thwaite, everything is either 8x8 (missiles, smoke, crosshair) or 24x24 (explosions) by nature, so 8x8 is a natural fit.

Some very detailed sprite animations are easier to do in 8x8. For example, 8x8 is more amenable to animating just the legs in an RPG character's walk cycle while reusing the head tiles. An overlay to add more colors to a small area, as in Mega Man series, causes flicker on fewer lines. And it's possible to simulate small amounts of rotation by shearing the sprite, moving individual 8-pixel chunks 1 pixel at a time.

The NES has no way to put a sprite half off the top of the screen, other than by using a top status bar and hiding sprites in $2001 while the status bar is being displayed. Sprites entering or leaving have to enter or leave all at once, and this is especially visible on a PAL NES. So 8x8 sprites help diminish this pop-on effect.

Super Mario Bros. 3 uses 8x16 sprites, and some of the enemies inherited from the original Super Mario Bros. had to be modified to fit this. Blooper (the squid), for example, is 24 pixels tall in the original but had to be redrawn smaller for SMB3.

Advantages of 8x16

The NES supports 64 8x8 sprites or 64 8x16 sprites. This means 8x16 sprites can cover a larger area of the screen. So games without many objects that are smaller than 12 pixels or 17-24 pixels in height can benefit from 8x16 sprites. These include fighting games, vertical shooters, or platformers without guns.

Using 8x16 pixel sprites can sometimes save CPU time. Say a game has four characters, each 32x16 pixels in size. It takes more time to write 32 entries to a display list than to write 16.

Some games, such as Crystal Mines (and its retreads Exodus and Joshua), repeatedly switch game objects from being part of the background to being sprites and back so that they can temporarily leave the tile grid. Super Mario Bros. 2 likewise does this for the mushroom blocks, keys, and the like. Because 8x16 sprites can use both pattern tables, an object can use the same tiles whether it is rendered as background or as sprites. This causes a problem, however, for games using a scanline counter clocked by PA12 like that of the MMC3 because fetching from both pattern tables causes extra rises in PA12, which confuses the counter circuit.

The NES supports 4 KiB for the background and 4 KiB for sprites. MMC5, however, has a 12K CHR mode that replaces background patterns with a third pattern table during sprite fetch time in horizontal blanking. This mode works only with 8x16 sprites because 8x8 sprites can use only one pattern table at a time.

Alfred Chicken uses a trick to completely hide attribute glitches when scrolling horizontally with horizontally mirrored nametables. It involves placing a column of blank sprites at x=248. But this is practical only with 8x16 sprites, as it needs 15 8x16 sprites or 30 8x8 sprites to cover the entire screen height.

External links