← All Essays
Technology 9 min read

Flicker and Slowdown

The NES could show 64 sprites but only 8 per scanline — and the two most familiar failure modes of the era have entirely different causes

Eight Per Line

The NES's picture processing unit can track 64 hardware sprites, which sounds generous, and can draw only 8 of them on any single television scanline, which is the constraint that actually governs everything. The reason is architectural: as the PPU prepares each line it walks the sprite list in order, finds the first eight that intersect that line, and copies their attributes into a small internal buffer. The buffer holds eight. There is no ninth slot. Sprites beyond the eighth on a given line are simply not drawn.

Left alone, this produces catastrophe. A boss made of six sprites plus two enemies and the player's bullets, all sharing a horizontal band, means somebody vanishes — and because the PPU takes the first eight in list order, the same somebody vanishes every frame. Objects disappearing permanently because of where they happen to sit vertically is not a graphical blemish; it is a game that cannot be played.

Flicker Is the Fix, Not the Fault

So programmers made the loss democratic. Rather than let the hardware silently drop whichever sprites fell late in the list, they tracked what was competing for each scanline and rotated the sprite order every frame, so a different subset was sacrificed each time. Nothing disappears permanently; everything appears most of the time; and the visual signature of the compromise is the strobing that anyone who played Contra or Mega Man can picture instantly.

This reframes flicker considerably. It is not the console failing — it is a programmer noticing a hardware limit that would break the game and choosing the least destructive way to distribute the damage. A flickering sprite is being drawn, just not every frame, and it remains trackable by eye and hittable by the player. The alternative was invisible objects that kill you. Flicker is the sound of the workaround functioning correctly.

Slowdown Is a Different Machine

Slowdown looks related and comes from somewhere else entirely: the CPU, not the PPU. Each frame the processor must update every object — physics, collisions, AI, timers — and hand the results to the graphics chip before the display needs them. Give it too many active objects and it does not finish in time; the frame is missed and everything proceeds in slow motion. This has nothing to do with the eight-sprite limit. A game can slow to a crawl with only a few sprites on screen if what those sprites are doing is expensive.

The two are confused because they appear together, and for an understandable reason: the conditions producing one usually produce the other. A screen crowded with enemies is simultaneously a heavy CPU load and a scanline-crowding problem, so slowdown and flicker arrive as a pair. There is also a genuine interaction — when the game slows, the flicker rate slows with it, so each strobe lasts longer and becomes much more noticeable. The visible flickering gets worse because the game is running slowly, which makes the two look like a single symptom of one underlying failure.

Designing Around the Ceiling

Once these constraints are visible, a great deal of 8-bit design stops looking like style and starts looking like engineering. Enemies arriving in small waves, bosses built from a few large sprites rather than many small ones, level layouts that stagger encounters vertically rather than stacking them on one line, projectile limits that cap how many bullets can exist — none of these are arbitrary. Each is a way of staying under a ceiling the hardware imposes without negotiation.

The best developers turned the constraint into vocabulary. Deliberate slowdown, for instance, became a feature in shooters, where a screen saturated with bullets slows the game and gives the player a fractional advantage precisely when the difficulty peaks — a hardware failure recast as a mercy. And the flicker itself has become period signature: modern games imitating the NES often reproduce strobing sprites for authenticity, faithfully simulating a workaround for a limit their hardware does not have. What was once a programmer's reluctant compromise is now an aesthetic choice, which is about the strangest possible fate for a bug-avoidance technique.