Maes
I like big butts!
Posts: 10176
Registered: 07-06 |
Sodaholic said:
I got a weird idea. What if you were to use a 16-bit colormap that represented the same 8-bit palette being overlayed over itself with transparency?
So, in essence, make a 16-bit Boom TRANMAP lump? It could be done, but it would give very little visual advantage, and it could only be used to blend the One True Doom Palette (or colormap #0) with itself.
The actual TRANMAP is supposed to return indexes so that after "blending", a further colormap effect can be applied (e.g. two colors A and B map to color C, which is then mapped to color Z due to sector lighting). If you make the TRANMAP contain precise RGB values instead, you won't be able to use colormaps for the final column rendering.
To cover all such cases, you'd need either a whole load of LUTs (memory and cache killer), keep the 8-bit indexing until the very end (only the final colormap will be 16-bit), or go full-blown RGB processing.
As usual, it's always a tradeoff between speed, convenience (from a programming standpoint) and flexibility. You can have any two of them at a time, but not all three.
E.g.
- Mocha Doom/Doom Alpha approach: it has speed and convenience, but it's not flexible beyond what their fixed colormaps allow.
- Full processing approach like _bruce_'s chocodoom truecolor branch: it has full flexibility and convenience, but sacrifices speed.
- A theoretical approach that has flexibility and speed would combine elements of both (e.g. dynamically generated colormaps, mixed colormap/full processing with caching whenever possible) but would not be convenient from a programming standpoint. MOcha Doom is actually verging on this, in order to achieve palette/gamma combined effects.
Sodaholic said:
EDIT: Oh, and what if you could assign assets their own palette?
It's possible, I've seen it done in a commercial game that used 8-bit resources on a 16-bit canvas, but in Doom you have the brick wall of the lighting effects, which would force you to use full processing. However, that game (Warlords Battlecry series) "cheated" by using resources that not only were 8-bit with their own palette, but also carried their own precalculated palettes for certain common in-game effects (e.g. to make sprites appear darker during night, "frozen", "turned to stone" or "on fire"). The Doom equivalent would be to have each sprite carry its own colormaps for all possible light levels, in addition to its own palette. The sprites in WBC had only 3 or 4 alternative palettes, though, not 32.
Edit 2: I kinda like this last idea. Anyone willing to prepare me a prototype sprite using a UNIQUE 256-color palette (not Doom's), e.g. a recolored imp? I will do the rest....my idea would be to have an extra set of lump marks e.g. XC_START and XC_END (eXtended Color), and have an extra lump for each sprite, e.g. TROOXC for imp (TROO). This lump would be just 32 colormaps in truecolor RGB format (32 x 768 bytes, 256 colors per map) or perhaps more. If the engine detects during loading that such a lump is available for a sprite, the sprite object will carry a reference to said colormap, and this colormap will be used instead of the common one for this sprite, thus allowing it to "break free", at least partially, from the One True Doom Palette.
Engines that don't have extended color renderers, can ignore it or try remapping the extended palettes to the Doom one.
Last edited by Maes on 10-07-12 at 20:09
|
10-06-12 22:10 
