Significant new feature: “Palette Swapping”. For performance reasons, we can’t do this in realtime (e.g. using it to make colors shift and change, like things are glowing or whatnot), but it’s enough to change the color of a whole level.
We’re planning to use this to recolor a few areas in the game for variety. The first caves in the game will be the above color-set, to match the exterior “seaside” rocks which are also brown.
Technical reason why we can’t do realtime: We’re not a nintendo, and our images are not stored on the graphics card, in indexed mode; they’re stored in absolute color. So we’d have to go through each entire image and change every single pixel to do it in realtime, which would collapse our performance.
“Yeah, but you could do that with this shader…” No, we don’t use shaders. Using them would dramatically raise the system requirements – notably, the iPhone doesn’t support them (neither do any other widely-used handhelds atm).
Having seen this effect in action, I like it!
Was just reading some literature on ALTTP in which the programmers used graphic compression to save memory for other functions in real time. Is that kind of what is going on here?
Uh.. no. Basically what they would have been doing in ALttP would have been compressing the graphics so they could 1] fit them in the game at all, and 2] fit them in the painfully tiny amount of ram the SNES had.
What I mean by realtime is “being able to change the palette every frame”. On the SNES, they used this thing called “indexed color” – instead of directly just writing what color every pixel is, one after another, they picked a small, arbitrary palette of colors, and gave them arbitrary numbers.
This unintentionally allowed them to do a very cool trick – because they weren’t directly writing down “this pixel is red”, and were instead writing down “this pixel is ‘color#1′”, they could switch around what ‘color#1’ meant, and suddenly, every pixel in the whole image that was color#1, would be a new color. This meant they could easily do flashing lights and change the color of something around.
With some extreme tricks, like lining up rows of “color#1,2,3,4”, and then making 1, then 2, then 3, then 4 each successively bright whilst the others were dark, they could make moving patterns, such as a waterfall.
This was fast, because they only needed to change it in one spot. [b]It’s kind of a lot like changing what key a song is in, by adding a flat sign to the very start of a line of music.[/b] In what we use, which is “absolute color”, we would have to painstakingly go over every single pixel in the image, one by one, check what color they are, and change them. Musically, this would be like going through the entire piece and putting a flat sign on each and every note we wanted to make flat. Same result, just takes a hell of a lot longer to do the second way.
What I mean by “real-time” is – this is just slow enough, the second way, that it (probably) would take too long for us to be able to do it between frames. If we tried, it’d slow the framerate down.
This isn’t guaranteed; we might actually be able to pull it off. But the key thing is – it’s not a trick built into our hardware (or any modern computer hardware) like it was on the SNES.
Wow. That’s insane about how they worked within the limitations of the SNES hardware. It’s nice we don’t have these hurdles!
Thanks for the info!
By the way, gifs are index color. That’s their main compression mechanism. Technically it’s a non-lossy format, but it can only represent pictures that are up to 256 colors. So when you save a picture with more colors as a gif, the program you’re saving with has to cut it down to 256 colors (quite possibly losing tons of detail).