Sprite Flicker
Exceeding hardware limits
Sprite flicker rapidly alternated which sprites displayed each frame, allowing games to show more objects than hardware supported at the cost of visible flickering.
Hardware had limits. Games exceeded them. When the NES could only display 8 sprites per scanline, developers used priority rotation to spread the unavoidable hardware drop-out across all objects each frame. The visible result is flicker — but flicker is the symptom; the technique is rotation.
Strictly: the PPU drops the 9th-and-later sprites on any over-budget scanline. Without rotation, the same sprites would always be dropped (whichever come last in OAM). With rotation, every sprite spends roughly equal time at low priority, so the flicker is distributed rather than concentrated.
Fast facts
- Purpose: Display more sprites than hardware limit.
- Method: Alternate sprites between frames.
- Trade-off: Visible flickering.
- Necessity: Game design demanded more objects.
NES sprite limits
| Limit | Specification |
|---|---|
| Total sprites | 64 maximum |
| Per scanline | 8 maximum |
| Overflow | Extra sprites invisible |
| Solution | Flicker rotation |
How it works
| Frame | Displayed sprites |
|---|---|
| 1 | Sprites A, B, C, D |
| 2 | Sprites E, F, G, H |
| 3 | Sprites A, B, C, D |
| 4 | Sprites E, F, G, H |
Result: All sprites visible, each at 30fps instead of 60fps.
Implementation approaches
| Method | Effect |
|---|---|
| Priority rotation | Cycle which sprites get priority |
| Random selection | Vary which sprites shown |
| Importance weighting | Player sprite never flickers |
| Scanline distribution | Spread sprites vertically |
Games with notable flicker
| Game | Situation |
|---|---|
| Contra | Many enemies/bullets |
| Mega Man | Boss fights |
| Gradius | Bullet hell moments |
| Zelda II | Combat scenes |
Alternative solutions
| Approach | Trade-off |
|---|---|
| Fewer objects | Reduced gameplay |
| Larger sprites | Fewer total |
| Different design | Avoid crowded scenes |
| Accept limits | Some sprites disappear |
Player perception
| Effect | Reception |
|---|---|
| Mild flicker | Acceptable |
| Heavy flicker | Distracting |
| Consistent | Becomes invisible |
| Erratic | Very noticeable |
Platform variations
| System | Per-scanline limit | Total sprites |
|---|---|---|
| NES | 8 | 64 |
| Master System | 8 | 64 |
| C64 | 8 (also the total; more by multiplexing) | 8 |
| SNES | 32 | 128 |
The rule is older than the NES
Texas Instruments’ TMS9918 — the video chip of the TI-99/4A, ColecoVision and MSX, and the ancestor of the Master System’s VDP set the pattern: “only four sprites can be active on any horizontal line. Additional sprites on a line will be automatically made transparent for that line.” The chip even reports the offender, setting a fifth-sprite flag in the status register and storing the number of the sprite that broke the rule. The NES and Master System raised the limit to eight; the shape of the problem, and of the rotation trick that answers it, is the same.
On the C64
The VIC-II has no separate per-line limit: it has eight sprites, full stop, and the Programmer’s Reference Guide says in the same breath that “more sprites can be displayed using RASTER INTERRUPT techniques”. So the C64 answer to too many objects is multiplexing — re-using the eight down the screen — and the limit reappears as a rule inside the multiplexer. Cadaver’s sort accepts the first eight virtual sprites unconditionally, then rejects any later one whose Y coordinate is within 21 pixels of the sprite already mapped to the same hardware slot, because the hardware could not show it. A rejected sprite does not flicker; it is simply not drawn that frame, and which sprites lose depends on the sort order.
Sprite zero and the priority trick
On the NES, sprite 0 is never flickered. It’s always evaluated first in OAM and is also used for the sprite-zero-hit flag ($2002 bit 6) — the standard mid-frame timing hook for status-bar splits. Games place a small-but-always-on-screen graphic (e.g. the score’s leading character) at OAM index 0 so its position is reliable.