"Palette swapping" now VS palette swapping then

If one wants to swap palettes in a modern game, one would use either GLSL shaders or create multiple images with different colors.
But on the NES, they obviously didn't have shaders. So how did they do it during actual rendering then? If one was to replace color pixel by pixel during drawing or draw anything at all pixel by pixel in a modern game performance would become very slow. The NES clearly found a very efficient way, so what was used? I cant find this straight info anywhere on the web including the wiki so I am asking here. Is the NES method of palette swapping impossible on modern hardware?

To be clear what I mean is how does it get from the data of "colors and tiles" to be drawn on the screen with said colors

PS The reason I ask is I was wanting to know if its possible or impossible to do 100% real palette swapping, not imitated using shaders, in a game these days? Thanks

There is only one palette (read: "set/choice of colours") on the NES. The colours depicted under the "Palettes" section are all you get. Background tiles and sprites get separate palettes, but the "set/choice of colours" (that you have to choose from) are the same across both. The Nerdy Nights tutorial goes over this as well.

For understanding the "format" of the data that defines what particular colour a pixel (as part of a tile), you need to understand this:

https://wiki.nesdev.com/w/index.php/CHR_ROM_vs._CHR_RAM
https://wiki.nesdev.com/w/index.php/PPU ... ute_tables

Overall, in my opinion, my nestech.txt document from days of old explains the latter a lot better (the wiki is over-complicated for beginners). Refer to Section 4, subsections D, E, and F (you may also want to read this). The Nerdy Nights tutorial also has a section on this.

Some advanced games use a combination of sprites and background tiles to give the visual impression of "more colours than normal". rainwarrior recently put together a video of Tecmo Bowl's intro that depicts exactly this (read the video description slowly to understand what is being shown).

For **extremely** advanced use, there is a demonstration from blargg that does this, however, this is EXTREMELY cycle-precise code and a lot of "PPU trickery". The wiki has details on how this was accomplished, as it does palette manipulation during HBlank: http://wiki.nesdev.com/w/index.php/Full_palette_demo (once more: EXTREMELY advanced topic). Because of how all of this is accomplished, it's really only plausible for a kind of demonstration, and not feasible for an actual game.

The rest of your statement is vague, with some parts that begs the question. "The NES surely found a very efficient way [to accomplish what I happen to think is going on]" is, uh, yeah... :P Every game is different. So why don't you provide some references to games which "found a very efficient way" [to "palette swap"] so we can explain to you what's actually going on (hint: 99% of the time, there is no "palette swapping").

Sorry, by palette swapping I meant setting the colors to use on a sprite, like how mario can become luigi as an example, is that not what palette swapping is? my probably very very incorrect current understanding is that tiles are just arrays of numbers and those are converted into colored pixels which is what i mean by drawing it to the screen, but like i said its probably wrong

From the wiki:
" Each sprite can use the three colors from one of the sprite palettes. The choice of palette is in attribute 2 of each sprite Sprites in the NES can use one of 4 possible sprite color SETS"

You can change("swap") an entire 16 byte SPRITE color set or a just certain colors during vblank

From the wiki:
"The NTSC video signal is made up of 262 scanlines, and 20 of those are spent in vblank state. After the program has received an NMI, it has about 2270 cycles to update the palette, sprites, and nametables as necessary before rendering begins."

If the rendering is off you can update as much as you want.

On the NES, the graphics are stored as 8x8 tiles. These tiles don't have color. They only specify where each color should go, not what it should be. To use your example, Mario's hat and Luigi's hat might both use "color #1", and the game will set "color #1" to be red for Mario and green for Luigi.

On modern systems, graphics are often bitmap textures with complete color information. Palette swaps are usually achieved by replacing the texture with one that looks similar but has different colors.

It's also possible for modern systems to use graphics similar to NES tiles, that specify where colors should go but not what those colors should be. In that case, the palette can be swapped just by changing the "what the colors should be" part.

Old graphics cards almost always used a "palette", which was a small chunk of comparatively very fast memory, able to transform a (usually) smaller number of bits to a larger number.

In the case of the NES and Sega Master System, this transformed five bits to six. The Game Gear 5→12; the Turbografx 16/PCE 9→9; the Genesis 6→9 ish (ignoring bright and dim modes); and the SNES 8→15. In the case of the Tandy graphics, 2→4; EGA card, 4→6; and the VGA card, gave the choice of either 4→6→18 or the simpler 8→18.

At some point in the development of modern graphics cards, it was decided that having dedicated hardware to do this was silly, and applying a palette to a picture is an embarrassingly parallel task, perfectly suited to a GPU's processing ability.

The NES does precisely this: it draws every pixel every frame. The PPU repeats the process of drawing the screen from pixel (0, 0) down to pixel (255, 239) 60 times per second (or 50, if PAL), based on data from the name tables, pattern tables, OAM, palette RAM and its internal registers. If any of these things change, the generated image will immediately reflect the changes.

The PPU was designed to draw images this fast, and it never slows down, because all of its tasks take a constant amount of time. What slows games down is physics, AI, and the overall complexity of the game world, but the PPU will still output 60 (or 50) images per second, even if some of these images are repeats due to the CPU not having enough time to change the video parameters.

Anyway, palette changes on the NES are fast because the program only has to change 25 bytes to select all new colors, and when drawing the next frame the PPU will repeat the entire drawing process, but using the new colors this time.

I don't know much about modern game programming, but I'm pretty sure that at lower resolutions you can still redraw the entire image pixel by pixel, since many emulators do that while running full speed. If you're going for higher resolutions though, I don't see why you'd need paletted graphics...

The easiest way to achieve the visual effect of paletted graphics is using graphics that use palettes. That's vector graphics. You can manipulate read data from an .svg or .xml file with very little load. That's one of the main reasons mobile interfaces rely heavily on vector graphics. Or you could come up with or call a colour replacement function in your library for raster graphics, but it won't be as fast. Preload everything you can.


The reason pixel by pixel manipulation isn't percieved as as fast on modern computers is not only because of resolution, but also because you've got countless buffers of gfx data added on top of each other or blended using algorithms (yet in more buffers) before sent to the final drawing stage. You only have two 'layers' on the NES (background, Sprite), and there's no blending mode, hence, it is "efficient", because the task is small and consistent.

Indexed color images such as png contain an embedded color table, right? Would it be possible to alter that data on the fly? As in load a png with an altered color table?

I think it's really just about GPUs. There was some support for indexed texture formats a long time ago, but it's pretty much died off, I think? Without GPU acceleration, you can't do as much stuff in the same amount of time, thus: "palettes are slow".

There a number of ways you can do palettes with the GPU otherwise, but there's generally a loss of efficiency vs. coloured textures, and possibly inconvenient to implement. (e.g. placing palette data in a lookup texture and using a shader to look it up per-pixel, separating paletted textures into colour planes and using shader constants and multiple layers to draw them...)


Replacing colours at load time is not generally a problem. Having to do it every frame is the problem: you are software rendering the texture, and then re-uploading it to the GPU.

But doing the lookup shader will still be cheaper than software rendering, correct?

Most likely, yes. The idea that palettes are slow on a GPU is usually a comparison against designing your application to not need palettes, or from a time where shaders weren't so ubiquitously supported.