Here's an old post I made on the subject,
What would be the point of a 16-bit palette?
Uhm... to use the same indexed lighting trickery of Doom with more colours? I think that was the whole point.
So why not go with 24-bit directly and get truecolor patches?
Sure, you get 65536 colors. Cool. But do you have any tool to generate such palettes? How about graphic software to use them?
Didn't look into it, but I assume that since an indexed 16-bit format is actually supported/defined, there must be tools that support them, too. Even if there weren't, that would 99.999% not be a problem, seeing how prolific developers can be.
TBQH though, the closest I've seen in practice was a RTS (Warlords Battlecry) that used a 16-bit indexed display but 8-bit sprites (with 16-bit palettes), and a great deal of the visual effects were achieved by using per-sprite and per-tile individually applied palettes.
You seem to be forgetting the needs of column-based software renderers, other than the on-disk storage. Not even OpenGL renderers utilize PNG directly (they would have to be converted to textures), and no software renderer so far is able to use anything other than raw 8-bit patch_t graphics. A 16-bit renderer capable of actually using 16-bit indexed column data, would also need a 16-bit patch16_t format, no matter if it was loaded from disk, forcibly blown from existing patch(8)_t or generated from PNG files by color downsampling.
As for a new patch_t format... Sorry, but I don't really see this happening anyway. It'd be redundant with things such as PNG, which are now adopted by several of the most influential ports out there (Eternity recently got PNG support, for instance).
*sigh* You too, Brutus? Of course a patch16_t format would be primarily a renderer hack, which could or could not necessarily have on-disk equivalents. I didn't suggest anywhere that it should be a FORCED and OBLIGATORY on-disk format (although it COULD be used for that too).
Graf Zahl said:
I agree. A 16 bit patch_t would be pointless.
Today there's no real need to have the external representation of a graphic be the same as the internal one.
As for going straight to 32-bit, at that point you are losing the advantages of indexed manipulation. A "patch32_t" format would be pointless, unless you accepted the overhead of doing straight RGB and/or Luma/Chroma manipulation.
Last edited by Maes on Sep 20 2011 at 13:18