Per Claude:
The key things the new comments add that the old ones were missing:
1. Palette RGB colors are completely ignored — only the index value is used as alpha. This is the non-obvious invariant that @notimaginative described.
2. Exact mapping table — makes the * 18 / * 17 math immediately readable, and clarifies the ANI vs PCX difference (> 15 clamps to opaque in ANI but transparent in PCX).
3. The broken-palette consequence — explicitly states that a reversed palette causes a white square, linking to #4148 so future readers understand the context.
FSO doesn't appear to use this any longer. And even when it was enabled the
requirements made it largely useless anyway. Removing to clean up cfile a
bit and so we don't have to keep maintaining it.
Code was moved around between 3.8.0 and 19.0.0 which broke the colored backgrounds of paletted HUD gauges.
Palette index 15 is used by the HUD gauge graphics to indicate background area of HUD gauges. When the code to remap palette indexes to alpha values was moved to packunpack.cpp, palette index 15 was mistakenly mapped to the alpha for index 0 (nothing) rather than index 1 (what retail/3.8.0 code maps it to) causing all HUD gauges to be missing their dark transparent backgrounds.
Also: the code maps palette indexes [0, 15] to alpha values [0, 255]. But due to an oversight (palette index 15 not being part of this gradient] alpha value 255 is never used so the range of alpha values for HUD gauges ended up being [0, 238]. Conversion math tweaked to make the alpha range [0, 252] which is very close to 255.
Currently, the graphics code does some color remapping on 8
bit-per-pixel textures since those textures use special 4-bit pixel
values. These changes move that conversion out of the graphics code and
into the image loading/font bitmap creation code.
The reason this is needed is because this conversion breaks 8-bit
textures that try to use the full range of colors. I need to do exactly
that for moving the cutscene renderer to our generic rendering interface
which I can't do at the moment since the existing color conversion
corrupts the video data.
I have tested this with retail data and could not find any visual
changes after applying these changes.
In commit 735f5e199b randomtiger changed how anim_load() worked in seemingly-bizarre ways, for reasons unclear to me. In brief, a condition's logic was reversed, a three-value enum was created of which only one value was used, and as a result loose files passed to anim_load() (and only loose files) would be opened as "memory-mapped", one consequence of which is that they'd keep a cfile block open until the corresponding call to anim_free() (which means that, if a mission had enough different loose animations, the cfile block limit could be reached). Since files in packfiles behaved the same way they always had (namely, being loaded into memory and then closed, thereby not taking up a cfile block), apparently nobody noticed the difference, and this inconsistent code has stayed for the past 13-and-a-half years.
This commit changes the condition after the one changed in the older commit so that they both match, then changes the enum so that the seemingly-meaningless third value is removed, and the other two values are swapped (and the default value of the file_mapped parameter to anim_load() changed) so that the original Volition behavior is restored.
Also includes support for more than two mainhall resolutions, zooming
so one mainhall can adapt to multiple resolutions, setting new mainhall
fonts, help overlays for all resolutions and adjustable tooltip padding.
Also allows preload screens to be any resolution & aspect ratio.
git-svn-id: svn://svn.icculus.org/fs2open/trunk/fs2_open@10844 387891d4-d844-0410-90c0-e4c51a9137d3
Goober5000