On the NES, flicker was a feature, not a bug.

Remember sprite flicker on the NES? Mega Man blinking in and out during a boss fight. Bullets vanishing between frames. Enemies half-disappearing when the screen got crowded. Most people assumed it was just the NES struggling under load, dropping things it couldn’t handle.

It wasn’t struggling. It was working exactly as designed. The flicker was the fix.

The NES PPU evaluates sprites using a block of memory called OAM, or Object Attribute Memory, which holds data for up to 64 sprites total. Each sprite entry contains an X position, a Y position, a tile index, and some attribute bits for palette and flipping. Every scanline, the PPU scans through OAM and finds every sprite whose Y coordinate places it on that line. It can draw exactly eight of them. If there’s a ninth sprite on any given scanline, that sprite simply doesn’t get drawn. No slowdown, no partial render, no error, it just doesn’t show up.

The PPU evaluates OAM in order, starting from entry zero. So if nothing intervened, the first eight sprites in OAM would always win and everything else would drop. In practice this means whichever sprites happen to occupy the low-numbered OAM slots get priority, and anything past the eighth on a crowded scanline disappears permanently for that frame. If Mega Man’s torso always lived in slots zero through three, his legs might vanish when enough enemies were on the same horizontal band. Bosses built from many sprites, stacked vertically across multiple scanlines but overlapping horizontally in places, would drop pieces depending on exactly where they stood relative to the player.

Sprite cycling is the solution. Every frame, the game rotates which sprites occupy which OAM slots, shifting the evaluation order so that different sprites get priority on successive frames. No single sprite dominates the low-numbered slots, so no single sprite reliably disappears. Instead, every sprite that would exceed the eight-per-scanline limit vanishes for one frame and reappears the next, alternating fast enough that persistence of vision blurs it into a flicker rather than a hard dropout.

The tradeoff is that the flicker is visible. At 60 frames per second, a sprite alternating between present and absent flickers at 30 Hz, which is fast enough to read as a complete object, but slow enough to be obviously unstable. It looks bad. But it looks bad in a way that keeps the game playable, and that’s the engineering judgment underneath it: visible flicker is better than invisible sprites.

Mega Man is the stress test for this system because Capcom built him to use it hard. Mega Man himself is assembled from multiple sprites. His head, torso, legs, and arm cannon are separate sprite tiles composed together. His shots are sprites. Every enemy on screen is a sprite. Bosses like Guts Man and Cut Man are large enough that they span multiple sprites stacked across several scanlines, and when Mega Man is firing at a one of those bosses, the total sprite count on some scanlines can blow well past eight. The game is essentially always in violation of the hardware limit during action sequences. Sprite cycling is the only reason you can tell what’s happening.

Other NES developers took a different approach. Super Mario Bros. keeps Mario and enemies small and manages their positions carefully to avoid stacking too many on the same scanline. Duck Hunt doesn’t have enough simultaneous sprites to hit the limit. Balloon Fight flickers noticeably when too many balloons are on screen. Same constraint, less aggressive mitigation. The games that barely flicker aren’t necessarily better engineered; they’re often just less ambitious about how many things they put on screen at once.

Contra flickers. Ninja Gaiden flickers. TMNT flickers badly enough that some enemies become nearly invisible in crowded rooms. All of them made the same calculation Capcom made: the gameplay we want requires more sprites than the hardware technically supports, and visible flicker is an acceptable cost for keeping the action intact.

The Bubble Lead weapon in Mega Man 2 is a good illustration of what sprite cycling looks like when you push it to the limit. Each bubble is a sprite. Fire enough of them and many will share scanlines simultaneously. The cycling is running as fast as it can and the result is a screen full of objects that are simultaneously present and not present, strobing at 30 Hz. It’s chaotic and it’s readable and it absolutely should not work as well as it does.