8X16 Sprites... Disadvantages?

8X16 Sprites... Disadvantages?
by WJYkK on 2010-03-27 (#59111)

Here's a curious question: because the NES gives you an option to use 8X16 sprites instead of 8X8 sprites, it would obviously be more beneficial. However, obviously with every advantage there are disadvantages. So, are there any problems with this method? If not, why do some people rather not use 8X16 sprites?

by tepples on 2010-03-27 (#59116)

The biggest disadvantage of 8x16 sprites is that they have more minimum blank space. This means bullets and the like will take up more space in your pattern table, and things will start hitting the 25% sprite overdraw limit and flickering earlier. And if you're using MMC3's scanline counter, the unique ability of 8x16 sprites to draw from both pattern tables becomes useless.

by Celius on 2010-03-27 (#59119)

There are actually several disadvantages to using 8x16 sprites. Like Tepples was saying, you have to define more blank space in your pattern tables for 1-tiled sprites. The disadvantage is that you HAVE to use 2 tiles, and the two tiles you use HAVE to be first an even tile ID, and then an odd tile ID. But the reason it's like this is so you can use from both pattern tables, which is pretty nice. Otherwise I'm sure they would have designed it so if you specify the sprite's tile ID as $20, it would use tiles $20 and $21, and if you specified it as $21, it would use $21 and $22, etc. But as it stands, if you specify tile $20, it uses $20 and $21 from the left pattern table, and if you specify $21, it uses $20 and $21 from the right table.

So this forces you to lay your graphics out in a pretty specific way. Also, 8x16 sprite patterns usually aren't as versatile as 8x8 sprite patterns would be. If you like to reuse sprite patterns for other sprites, using 8x8 is really good because the peices are smaller and are therefore less specific graphically. 8x16 patterns often include peices of graphics that prevent you from reusing them. For example, say you have an enemy with a head that's 8x8 pixels, and its upper arm is also 8x8 pixels. Pretend that you're using 8x16 sprites, and you define it so the head and the upper arm are both in the same 8x16 sprite. When the enemy starts walking, you want to move the upper arm. However, since the 8x16 pattern includes both the head and the arm, you can't re-use the head part because you want the upper arm to move. This forces you to use a different sprite pattern for the arm movement, which means you have to redefine the head since it's paired with the arm. There are ways to avoid this, but not always.

For my NROM project, I decided I had to use 8x8 sprites, because I simply could not afford to waste space with only 8k of CHR data for the entire game. So the space thing is really important to consider.

And also, what Tepples said about MMC3 is true. If you want to use the scanline counter, you can only use sprites from the left pattern table (this is also true with 8x8 sprites; you have to set it up so BG is on the right, and sprites are on the left). I'm not sure why this is, I just know that it's true (and lame). In many cases, 8x16 sprites are helpful (like if you want big sprites. In one of my project, I truly have half the sprites unused most of the time). But for versatility and conservation of space, you'll want 8x8 sprites.

by MottZilla on 2010-03-28 (#59171)

Celius wrote:
And also, what Tepples said about MMC3 is true. If you want to use the scanline counter, you can only use sprites from the left pattern table (this is also true with 8x8 sprites; you have to set it up so BG is on the right, and sprites are on the left). I'm not sure why this is, I just know that it's true (and lame).

It's because the MMC3 scanline counter works by watching accesses to certain CHR address space. Every scanline has a fixed amount of pulses if there are only Background tile fetches. However if you have a sprite on the screen using the background's side of the pattern table, it throws off the counter as there were additional pulses. MMC5 does not suffer this as it must use a different method of keeping track of the scanline. CPU based IRQ including the Konami VRC4 are unaffected and could use 8x16 sprites from either side of the table.

by Bregalad on 2010-03-29 (#59223)

Quote:

And also, what Tepples said about MMC3 is true. If you want to use the scanline counter, you can only use sprites from the left pattern table (this is also true with 8x8 sprites; you have to set it up so BG is on the right, and sprites are on the left). I'm not sure why this is, I just know that it's true (and lame).

Basically the PPU does all BG related fetches (nametable, attribute table and BG pattern table) and then does all sprite related fetches (sprite pattern table) each scanline, and repeat this.
So if BG uses the low pattern table and sprites the high pattern table, A12 will remain low for all BG fetches and high for all sprites fetches, effectively clocking the counter once per scanline.

If BG uses right pattern table, A12 will toggle many times during BG fetches as it altenrate between pattern tables and name table fetches so the counter will be clocked more than once per scanline.

If any sprite uses the left pattern table, A12 will also toggle during sprite fetches, and will clock the counter (more than once per scanine).

If you do $2006 writes it's possible to manually clock the counter too.

It is actually possible to use the counter under the previous conditions, but you'd have to predict the extra clocks of the counter.

Hoping this clears things up.

Last call bump
by tepples on 2013-08-09 (#116280)

This topic about enabling rendering late drifted to yet another discussion about the merits of using 8x16 or 8x8 pixel sprites. I thought about restarting the discussion with more focus, but I searched first and found a whole bunch of previous topics like this and this and this and this and this. I plan to summarize them to a page on the wiki, so I'm bumping to see if there's anything I missed.

8x8 is better for these:

Tiny bullets, smoke particles, or puzzle pieces, because 8x16 wastes pattern table space and increases potential for dropout or flicker on more adjacent lines
Faux rotation through sprite shearing
Characters 24 pixels tall, like Mega Man and the hero of Balloon Fight
Tile reuse when animating individual parts of a character

In Thwaite, for example, everything is either 8x8 (missiles, smoke, crosshair) or 24x24 (explosions) by nature, so 8x8 is a natural fit. Likewise with a couple other projects I'm planning: 24 pixel characters, 8x8 pixel rope pieces, and shearing.

8x16 is better for these:

Games without many objects that are smaller than 12 pixels or 17-24 pixels in height, such as fighting games, RPGs, or platformers without guns
Saving CPU time by writing fewer OAM entries per sprite
Reusing unused space in the background pattern table or moving background objects in and out of sprites, such as Crystal Mines/Exodus, so long as the game doesn't use a PA12-clocked scanline counter like that of MMC3
Games using MMC5's 12K CHR mode, which allows the use of three separate pattern tables for the background, even-numbered 8x16 sprites, and odd-numbered 8x16 sprites

Super Mario Bros. uses 8x8 sprites. Enemies are rendered 24 pixels tall, though most enemies actually use only 16 of those pixels. Super Mario Bros. 3 uses very similar enemy designs with 8x16 sprites. Some enemies that were 24 pixels tall in the first game use additional sprites, such as Koopa Troopa that has an extra sprite for the head, and a few others are cut down, such as Blooper.

Re: Last call bump
by sonder on 2013-08-09 (#116283)

16x8 has some more interesting caveats i've found through creating graphics within this constraint.

when a sprite leaves the top of the screen, it leaves sooner than 8x8 does.

16x8 sprites allow invasion of the background's patterns. use of some tiles as priority-quirk sprites is possible but you have to account for the other tile in the 16x8 pattern. interestingly the other tile can be a normal bg tile, containing any non-zero values, if you want it to be "all-masking", since in theory it won't be seen anyway.

it's my opinion that 16x8 tiles are still useful for creating sprites as short as 10 pixels. i made a lot of items like this. due to the NES stretched aspect ratio this enables you to create more even circle-shaped objects by drawing them slightly stretched out. Zelda did this - maybe a little too much imo though as fireballs looked oddly tall.

Re: 8X16 Sprites... Disadvantages?
by tepples on 2013-08-09 (#116284)

On NTSC, something 7x8 pixels in size is a perfect square/circle by definition. (Rec. 601 defines the active width of a scanline as equivalent to 280 dots, giving 8:7 PAR that a 7x8 pixel object cancels out.) But on PAL, you're right that 8x11 is closer.

I'm not sure what you mean by "invasion of the background's patterns."

Re: 8X16 Sprites... Disadvantages?
by sonder on 2013-08-09 (#116288)

tepples wrote:
On NTSC, something 7x8 pixels in size is a perfect square/circle by definition. (Rec. 601 defines the active width of a scanline as equivalent to 280 dots, giving 8:7 PAR that a 7x8 pixel object cancels out.) But on PAL, you're right that 8x11 is closer.

I'm not sure what you mean by "invasion of the background's patterns."

In 16x8 mode sprites can address the entire 8k CHR address space.

Re: 8X16 Sprites... Disadvantages?
by tepples on 2013-08-25 (#117047)

http://wiki.nesdev.com/w/index.php/Sprite_size

Anything need added?