When you look at the technical specs of the Super Nintendo, that number of 32,768 available colors really stands out, especially compared to the Sega Genesis's 512 colors. But in practice, game development dealt with a completely different reality. The problem was never the global palette itself, but rather how the hardware managed memory and distributed those colors on the screen. In the end, programmers had to deal with annoying VRAM bottlenecks and a very rigid sub-palette structure. To understand where the headache started, it's worth remembering that the console could rarely display more than 256 simultaneous colors on screen in most common visual modes, like Mode 1. And those 256 colors weren't free to be used on any pixel; the system divided everything into rigid groups. There were 8 sub-palettes for sprites (the objects and characters) and another 8 for the background layers. Each of these small groups could only hold 16 colors. To make things a bit worse, the first color of each group was strictly reserved for transparency, which reduced the actual limit to **15 visible colors** per character or background element. This is why we saw so many palette-swapped enemies in games from that era. It was just the easiest way to save space in the palette memory (CGRAM) without having to draw new graphics from scratch. Another heavy barrier was the VRAM, which was only 64 KB. If a studio decided to use Mode 3 to have a super detailed background in pure 256 colors, that background alone swallowed twice the memory a standard 16-color background would occupy. Usually, the price for this was a lack of space for sprite animations. Developers spent a massive amount of time calculating what to cut just to make the game fit into memory and run acceptably. Even with these constraints, people found ways around them using a few interesting hardware tricks: * **HDMA (changing the palette mid-render):** This feature allowed data transfers to the video chips line by line while the image was being drawn on the TV. This explains those nice sky or water gradients in many games; the palette changed colors mid-scan, giving the impression that the console was displaying far more colors than its standard limit. * **Color Math (native transparency):** The SNES graphics chip could add or subtract colors from two different layers in real time. Instead of wasting palette slots to draw a fog, light, or shadow effect, the hardware blended the images together. This generated new shades on screen without using a single byte of palette memory. * **Dithering:** Studios like Rare used pixel-meshing techniques with different colors. On CRT TVs of the time, these dots blended together slightly, tricking the human eye into seeing a smooth gradient where, in reality, there were only a few solid colors. A lot of people still wonder why some Genesis games looked sharper or more vibrant despite a theoretically worse palette. The main thing is that Sega's console usually ran at a higher horizontal resolution (320 pixels compared to the SNES's 256). Since Sega's artists knew they had few colors, they used highly saturated, high-contrast tones. On the SNES, trying to use softer, pastel tones within that 15-color-per-sprite limit sometimes resulted in a slightly washed-out or blurry look, partly due to the lower resolution and the console's video output filtering. In the end, Nintendo didn't add more memory or larger sub-palettes simply due to manufacturing costs back in 1990. Fast memory chips (SRAM), which the graphics chip needed, were incredibly expensive components back then. Adding more VRAM would have made the system unaffordable for most families. Later games, like *Yoshi's Island*, were only able to deliver extraordinary visuals because they used extra coprocessor chips inside the cartridge itself—like the Super FX 2—to help draw things and relieve pressure on the console. It was a clever workaround for the industry, but it really highlighted how the original hardware base had very defined physical limits.