To elaborate on this a bit in case it's still confusing for anyone: Until the mid-1990s or so, memory was too expensive to routinely store RGB values [1] for e

To elaborate on this a bit in case it's still confusing for anyone: Until the mid-1990s or so, memory was too expensive to routinely store RGB values [1] for every pixel on consumer-grade hardware, so sprite/texture/etc. assets effectively contained a narrower type "pointer to color" instead of a wider type "color", typically translated on-the-fly by the video hardware by way of a small and fast palette RAM. This meant that by altering the underlying array of actual colors, an impressive breadth of animation and "compression" tricks could be achieved with little CPU time and no manipulation of the underlying pixel data (which, for NES and arcade games, was often stored in a dedicated ROM directly read by the video hardware). The classic example is a halo of torchlight cycling through a handful of red/orange/yellow values, but it's been used for a vast spectrum of effects by a bunch of extremely clever artists, programmers, and artist-programmers. [1] It happens to be the case that Famicom/NES color is fundamentally based on the phase encoding of composite video and so doesn't strictly map to a single definitive RGB color space, but the basic principle otherwise applies.