How to set number of sprites

I have read that the SNES can display up to 128 sprites, eg in this doc:



Is it possible to display fewer than 128 (as the above quote suggests one can and should)? How should the number of sprites be specified? IIUC zeroing all 544 bytes of OAM will result in 128 identical copies of character 0 being drawn.

Set all sprites' Y position to $E0 or $F0 and they probably* won't be displayed.


* Unless you're using 239-line mode with 32x32 and 64x64 pixel sprite sizes.

I'm not sure if it was explained in the document, but the reason for the sprites "screwing up" happens when there are too many sprites on single scanline and the PPU ignoring some of them. The PPU considers sprites as 8x8 pixel regions regardless of the sprite size setting, so if you use 32x32 sprites, the PPU sees it as 4x4 arrangement of 8x8 pixel sprites. This is at least what I've read on this subject.

You can also move large sprites off the screen with the extra bit on the x coordinate, since sprites wrap around to the top of the screen from the bottom, I think you can only put a 16 pixel high sprite on $E0. Having taller sprite or moving it down further will make it appear through the top of the screen.

The limit on SNES is 272 pixels/lines or 30 sprites/lines
(If we compare it to the MD, it's 320 pixels/lines or 20 sprites/lines and the neo geo is 96 sprites/lines of 16x16 equivalent to 1536 pixels/lines ).

Not quite. The PPU has a rigid sequence of tasks it executes to display sprites reliably every line, and the result is that each line can have a maximum of 32 sprites (not 30) or 34 8x8 tiles on it, whichever is lower. Any more than that, and it simply runs out of time and doesn't bother processing the extra sprites/tiles.


If you do this, you should make sure the bottom 8 bits aren't all zero. Setting a sprite to exactly X=256 results in it and all of its tiles counting towards the scanline limits.

It's unfortunate, but there isn't a single easy 100% foolproof way to disappear a sprite on SNES. It's not hard, but there are gotchas either way you do it.


Those MD limits only apply to H40 mode, where 320 pixels (40 tiles) per line is one screen width. In H32 mode it's 256 pixels (32 tiles) or 16 sprites per line. To be fair, H32 mode was only really useful for software rendering, ports and Master System backward compatibility; in H40 mode the whole VDP was upclocked, so everything from sprite rendering to DMA was faster in direct proportion, and there were no real disadvantages like there were with 512-pixel mode on SNES.

Speaking of 512-pixel mode on SNES, it doesn't apply to sprites. You can use interlace to get vertically high-resolution sprites, but horizontally they always render in low resolution, so the scanline limits and their practical implications remain identical.

The Neo Geo only had one non-scrolling BG layer (they called it the "fix" layer), so everything but the HUD was done with sprites. The screen was technically 320 pixels wide, or practically 304, so discounting the fix layer you had a little over five screen widths of sprite overdraw - but that had to cover everything that a system like the SNES or the MD would use scrolling background layers for. Very powerful and flexible (especially considering the sprite shrinking capability and the enormous number of palettes), but not quite as massive as it sounds.

Thanks all. IMHO this is not obvious to newcomers so I added some notes to https://wiki.superfamicom.org/sprites