How did early game consoles achieve smooth scrolling without modern GPUs?

24 Eki 04:16

When I was messing around with an NES home‑brew project back in college, the first thing I hit was the hardware scroll registers (PPU $2005/$2006). Those two 8‑bit registers let you shift the whole nametable by a pixel or a tile in one go, so the MCU never had to redraw each pixel – it just told the picture‑processing unit “start rendering from this offset”. The screen was built from 8×8 tiles stored in VRAM, and the PPU fetched the appropriate tile data on the fly as the scanline swept across. Because the tile map is essentially a 2‑D array of indexes, moving the viewport is just a matter of incrementing the base address or the fine‑scroll bits, which is why side‑scrolling felt buttery smooth despite the 1.79 MHz CPU. Sprite multiplexing was another clever trick. The hardware could only display 8 sprites per scanline, so games like *Contra* would time‑share sprites by re‑using the same sprite slots on different scanlines – essentially “re‑programming” them mid‑frame during the VBlank or even during the active line using raster interrupts. This kept the sprite engine lightweight and let the CPU focus on updating tile attributes rather than drawing every pixel. Compared to modern GPUs that shade each pixel individually, these consoles did almost all the heavy lifting in dedicated video hardware, so the CPU stayed free to handle game logic while the PPU streamed tiles and sprites in real time. That division of labor is why early consoles could pull off fluid scrolling with such modest silicon.