if drawables could be accessed as arrays of bytes in a quick and efficient manner, it wouldn't be difficult to code a seek and replace function.
Better still if images could be defined from the start as palettized rather than full color, they could be altered by simply changing 32 bytes or so.
Really the only requirement for supporting palette swapping is allowing access to the memory that defines the image, which is something most engines don't do, presumably for either lack of necessity or lack of desire to deal with user-created issues.
I feel like a 2D pixellated engine would benefit a lot from handling this kind of interaction, but I also realize as a coder, how much hassle it could create.
If solarus ever picks up support for compiled shaders, it wouldn't be difficult to use a fairly lightweight shader to handle palette swapping...
however, shaders are their own box of problems to implement.
It all comes down to time and labor really.
Edit: one of the massive advantages palettes have over duplicated sprites, that hasn't been mentioned, is the ability to alter the colors of the sprite while it is in the middle of an animation, without losing track of frames or having to reload any sprites.
This is how the link-is-damaged flashing was achieved in in all of the 2D zeldas (and most 2D games from the 16 and 8 bit eras in fact).
This is how link can be flashing invincible, while still walking around. His palette would be replaced by red yellow and black or some similar series of colors.
This is also how a lot of water and fire animation was achieved. A single static image of a waterfall would exist in the game, and it would have a palette that rotated from dark to light.
This would be easy to achieve in a more modern way with per-object shaders. I've already written a very simple shader to do it, but I don't know how or if it is possible to apply it to anything in the engine as of now. The entity page is listed as mentioning shaders in the 1.6.0 documents' search, but it does not contain any references to shaders.
