Hey everyone, I was just doing to retro games thing (Playing Super Metroid and watching playthrough videos on Youtube) when something dawned on me. Video games stopped using the pallet swapping techniques that made colors that went crazy. From what I understand it consists of taking a system’s color pallet and screwing with the calls. The result is what Mario looks like when he picks up a star in Super Mario Brothers. It has been used in a multitude of games and gives a very unique look.
Contra Hard Corps is full of examples of this:
Note what happens when the boss gets hit at 0:39.
So my question is, what happened?
Is it because systems no longer use fixed pallets?
And if so couldn’t you do something clever involving PNG files?
Or is this possibly for the benefit of epileptic people?
Well no, I wouldn’t think that would be the most efficient way of doing that. You’re talking about swapping out multiple image files over simply reassigning colors. I’m not so sure you could do that and get the same effect, even with modern hardware.
If you want you can do palettised textures using a shader - you would simply use an 8bpp texture and another small texture to use as a palette. I don’t know if it would be worth the bother, though. You could just write a shader to do whatever hit effect you wanted instead.
In those old games colour values aren’t stored in the sprite itself, they are stored in an external list of colours called a palette, from which they are referenced by index. When doing that, it’s fairly easy to use the same index but pull colours from a different palette just by changing the pointer to the palette used for drawing. Changing that pointer is the actual “palette swap”.
In modern textures, however, the colour value is stored directly in the texture itself, and is not an index into an external list of colours. Thus there is no pointer to the palette, which means that palette swapping is fundamentally impossible. Additionally, because you’d have to modify the texture itself, “reassigning colours” isn’t so “simple” (well… I guess it could be considered simple, but it certainly isn’t cheap).
As the guys have said above, palletisation was a technique borne of necessity to minimise memory usage, and once that was done it added relatively little memory usage to animate by swapping palettes. These days it’s simply not necessary, and there are other, far more flexible ways to make effects. People could make a colour effect that looked exactly like old school palette swapping if they wanted, but they simply choose to do other things instead.
Years ago, true color displays were unheard of. Back in the late 80’s for example most PC’s could only handle 4 or 16 colors. There was almost no such thing as a dedicated graphics card. It wasn’t until maybe the early 90’s that pc’s started to have a whopping 256 colors. The thing was, the hardware was so slow by today’s standards that it was barely even possible to pull up and display one byte of memory for each pixel. In fact, other computers such as the once popular Amiga (best home computer platform ever would work in number of bits per pixel as ‘bit-planes’, for example 5 bits per pixel giving 32 colors. The thing was, when computers were limited to like 16 color displays it was really hard to properly represent a real image or photo without it looking awful. The colors you could use were fixed! So there was great demand for two things: more simultaneous colors, and the ability to specify what those colors were with more accuracy. So graphics hardware would start to implement indirect color palettes, ie you were allowed to modify what colors were displayed. The way it mostly worked you’d have a small list of color values, and then each pixel’s value would be an offset into that ‘lookup table’. At first the amount of bits that each color could be represented with was limited, for example you might have 32 simultaneous colors from a 12-bit palette, ie 4096 possible colors. Graphics cards started pushing toward 256 colors from bigger palettes, e.g. an 18-bit palette of 262000 colors. The Amiga was eventually able to refer to a 24-bit color palette with 256 simultaneous colors. But then came 16-bit ‘high color’. Obviously with 65536 simultaneous colors it starts to become inefficient to store 2 bytes per pixel plus a huge array of 65536 palette entries, so palettes color displays met their demise. And once 24-bit true color came along it was all over.
So back in the day one if the animation tricks was to modify the lookup table if colors. The thing was, because every pixel on the screen referencing a given color would read from that lookup table, changing the color palette entry changed the color if every pixel referring to it instantly, as a way that the hardware was working with absolutely no extra overhead beside time taken to write to the palette. This became an artistic tool, creating sequences of color indexes which, when all of the colors within a range if indexes were shifted or ‘cycled’, the sequence would appear to animate on the screen. It was very fast to do with little CPU overhead which was an extremely valuable resource back then (e.g. a 7 MHz CPU could easily color cycle the whole screen yet be totally incapable of animating more than a handful if sprites smoothly). And so ‘color cycling’ was born and had its time in the limelight until faster display hardware came along.
You can easily do color cycling in a shader. Simply put a palette into a second texture. Then your main texture (which could be Alpha8 format for 256 colors) contains the indexes to the palette colors. Cycling the palette is simple, just add a base offset to the color indexes, and wrap the high values back around to the low end.
It is an old technology but has some uses. If you need to conserve memory on mobile you can use paletted images, at the extra expense if an extra 1 byte texture read per pixel - but with the benefit if 4x the memory storage.
I’m making very heavy use of color cycling in my current game project, it’s really cool to work with.
Thank you everyone. I don’t really plan on using this atm, but learning is always fun. Imaginaryhuman, your vast knowledge of rendering manages to stagger me once more. Thank you.
EDIT: And just to clarify, without pointers that means this is impossible to do with true java (not Unity java) without a work around, correct?
There are many things you can do with shaders to reproduce some of those effects, but they will be a bit more complex. At the extremely easy side, you can simply change the Color property of a difuse shader when the player is hit, to do a red-flashing hurt/imunity color, for example (did this in Misu Misu Kaboom!)
You can always make more complex shaders that take secondary “paint maps” if you want to only change the colors of some bits of the character. Imagination (and time!) is the limit.
Oh, I’m not. To be honest I’ve yet to figure out what I want to do at all. I just like learning. And I thought that an array would be too taxing. Am I mistaken?
Dated effect, created out of necessity. The only reason I would use something like this would be re-creating it.
Anyway tone-mapping is a technique similar to this, it is also used to alter visuals, it’s just a bit more sophisticated.
Well using an array to do a lookup table to change and animate a texture indicates you’re using the CPU which has to then get the modified texture to the graphics card (presumably) for display, which is overall going to quite slow.
If I was implementing something that mimics palette swapping I would do the table lookup on the GPU in a shader. I haven’t tried it but it seems likely to work well and be very fast.
What happened to “pallet swapping” was that it was outlawed.
It was deemed too dangerous to do after numerous industrial accidents involving workers who tried to do “pallet swapping”.
After the great pallet swap disaster of 98’ - the world finally had enough. Laws were enacted and treaties were signed to ban all pallet swapping. It was an end of an era of major disasters.
.
Joking aside - you can still do “palette swapping” with grayscale texture.
What you do is simply using a grayscale texture - and then simply changing the hue - the grayscale texture acts as reference numbers (or lookup table) - and you map a new color to that.
It is still an immensely useful method - its NOT oudated.
Think of MMO, or any games where you want to allow players the options to change the color scheme of their attires (clothing) while keeping the pattern on it the same. Changing color dynamically using shader is always faster and saves more memory/storage than simply swapping texture - let’s say what if you have 10,000 different attires for players to choose from and a variety of color choices? If you use the texture swapping method - you would have to create a color for each 10,000 variations - and even with conservative 256 colors per variation u will need 2,560,000 textures!
Its easiest to spot this effect on hair in MMO - in which the hair is just a grayscale texture and colorized procedurally.
So, yes it is still used in games. The idea of it at least anyway.
Some games like Point and click made really creative use of this technique like Indiana Jones and the tales of atlantis where it’s use for simulating a river for example.
would work in number of bits per pixel as ‘bit-planes’, for example 5 bits per pixel giving 32 colors. The thing was, when computers were limited to like 16 color displays it was really hard to properly represent a real image or photo without it looking awful. The colors you could use were fixed! So there was great demand for two things: more simultaneous colors, and the ability to specify what those colors were with more accuracy. So graphics hardware would start to implement indirect color palettes, ie you were allowed to modify what colors were displayed. The way it mostly worked you’d have a small list of color values, and then each pixel’s value would be an offset into that ‘lookup table’. At first the amount of bits that each color could be represented with was limited, for example you might have 32 simultaneous colors from a 12-bit palette, ie 4096 possible colors. Graphics cards started pushing toward 256 colors from bigger palettes, e.g. an 18-bit palette of 262000 colors. The Amiga was eventually able to refer to a 24-bit color palette with 256 simultaneous colors. But then came 16-bit ‘high color’. Obviously with 65536 simultaneous colors it starts to become inefficient to store 2 bytes per pixel plus a huge array of 65536 palette entries, so palettes color displays met their demise. And once 24-bit true color came along it was all over.
