*[public-colormap-overhaul](https://github.com/STJr/SRB2/compare/next...mazmazz:public-colormap-overhaul) - Colormap rewrite to support new features
*[public-colormap-overhaul-change-ldef](https://github.com/mazmazz/SRB2/compare/public-colormap-overhaul...public-colormap-overhaul-change-ldef) - LD 447 Change Colormap by MonsterIestyn with adding colormaps together
*[public-fof-fix-movingplat](https://github.com/STJr/SRB2/compare/next...mazmazz:public-fof-fix-movingplat) - Fix bug that snaps player Z when disappearing moving platform
Type 420 Fade Lighting took an input `x/tic` to change the lightlevel x times per tic.
I added the ability to specify how long the fade should last in tics. Per frame:
* I take the (percentage of duration that elapsed)
* I apply that percent to (endlightlevel - startlightlevel)
* Then I add that to the startlightlevel.
I added these flags to the special:
*`ML_EFFECT4` - Enable tic-based logic
* ~~`ML_TFERLINE` - Use exact light values for OpenGL. Else by default, lighting is snapped to the 32 Software levels.~~ removed, no reason to have this
*`ML_DONTPEGBOTTOM` - Use alternate inputs. Else by default, use the old sector brightness and line length inputs.
*`Front X Offset`: Brightness level to fade to
*`Front Y Offset`: x/tic speed, or if `ML_EFFECT4`, then duration in tics.
# Colormap code overhaul
To support fading colormap features, I overhauled the colormap generation code to support an arbitrary # of `extracolormap_t`s and some other stuff for ease of use.
Based on MonsterIestyn's code cleanup.
## Changes
The core changes are:
* Clean up `extracolormap_t` to have only metadata variables like RGBA, fadestart, fadeend, and fog; and the lighttable itself.
* Remove the `MAXCOLORMAPS` limit and `extra_colormaps[]` table and replace with a next/prev struct chain
* New property `side_t->colormap_data` for storage during setup. `sector_t->extra_colormap` is for rendered colormaps only.
* This means multiple colormap lines can take the same control sector without conflicting. Also, colormap changes work for tag 65535
* Split `R_CreateColormap()` into `R_CreateLightTable()`, so that any code can create an arbitrary `extracolormap_t` and generate a colormap table for it
* Smarter colormap string parsing, so that a map author can specify just alpha (`#A`) or just red (`#RR`) or just red and green (`#RRGG`) or nothing at all. Unspecified values have defaults.
* Utility functions, such as:
* Checking colormap equality
* Checking if colormap is equivalent to default (no colormap)
* Adding two colormaps together.
* #ifdef'd out colormap lump code because it's unused anywhere else; but it's updated to fit the new code.
Other areas updated:
* Netsync support for colormaps: compare sector's current colormap to its spawn colormap
* Make sector `lightlist_t` auto-update to colormap changes like it does to lightlevel, for FOFs.
* This is done by storing a reference to a sector's `extra_colormap` (which is itself a pointer). The renderer code is updated for this as well.
# Linedef Exec 447: Change Colormap relative value calc
This rebases Linedef Exec 447 Change Colormap on !189 Colormap code overhaul and adds the following features:
*`ML_EFFECT3`: Calculate change relative to the target sector's current colormap (i.e., this line's RGBA values are added onto the current colormap's RGBA values)
*`ML_EFFECT1`: Subtract R
*`ML_NOCLIMB`: Subtract G
*`ML_EFFECT2`: Subtract B
*`ML_DONTPEGBOTTOM`: Specify base alpha by `Front X Offset` and fade/dark alpha by `Front Y Offset`. Set negatives here to subtract alpha if `ML_EFFECT3 is set.
* `ML_TFERLINE`: Use the back sidedef's colormap instead of the target sector's current colormap to calculate relative change
* `ML_EFFECT3`: Calculate change relative to the target sector's current colormap (i.e., this line's RGBA values are added onto the current colormap's RGBA values)
* `ML_EFFECT1`: Subtract R
* `ML_NOCLIMB`: Subtract G
* `ML_EFFECT2`: Subtract B
* `ML_DONTPEGBOTTOM`: Specify base alpha by `Front X Offset` and fade/dark alpha by `Front Y Offset`. Set negatives here to subtract alpha if `ML_EFFECT3` is set.
* `ML_TFERLINE`: Use the back sidedef's colormap instead of the target sector's current colormap to start fading
* `ML_BOUNCY`: Disable behavior where fading from no colormap overrides the target sector's RGB colormap value (because by default, it's #000000, so the behavior is to initialize that to the destination colormap's RGB value but not the alpha)
* `Front Y Offset` or `Back Y Offset`: Fade speed increment, out of 256 (unless `ML_DONTPEGBOTTOM` is set, then this must be `Back Y Offset`)
* `ML_EFFECT4`: Specify fade duration in tics instead.
## 456 Stop Fading Colormap Spec
* Nothing! (Tagged sector stops the fade thinker)
# Linedef Exec 492: Fade PolyObject
Add translucency fading for PolyObjects.
No Stop Fade special this time, because the other specials also do not have a stop mechanism.
Other tasks I performed:
* I fixed Linedef Exec 490 Set PolyObject Visible to set the correct render flags according to spawnflags.
* I added a couple flags for Linedef Exec 491 Set PolyObject Translucency
## 492: Fade PolyObject Spec
* `Front X Offset` OR `Front Floor Height`: 1000-based alpha value to fade to, like Type 491
* `ML_DONTPEGBOTTOM`: Specify raw translucency value instead
* `ML_EFFECT3`: Calculate relative to current PolyObject alpha
* `Front Y Offset`: x/tic increment speed, out of 256.
By default, this affects the alpha level; and, as appropriate, toggles `FF_EXISTS`, `FF_TRANSLUCENT`, and collision flags like `FF_SOLID`. Toggles exist to disable these behaviors.
* `ML_EFFECT3`: Alpha target is relative to current FOF alpha. Negative value subtracts.
* `ML_NOCLIMB`: Do not handle `FF_TRANSLUCENT` and appropriate culling flags like `FF_CUTLEVEL`
## Type 453: Fade FOF
* `Front X offset`: FOF target sector tag
* `Front Y offset`: FOF control sector tag
* `Back X offset`: Alpha target, 1-256
* `ML_EFFECT3`: Alpha target is relative to current FOF alpha. Negative value subtracts.
* `Back Y offset`: Speed, x/tic, 1+. If 0, then set immediately without fade.
* `ML_EFFECT4`: Timing is tic-based (`Back Y Offset` refers to tic duration)
* `ML_BLOCKMONSTERS`: Do not handle `FF_EXISTS`
* `ML_NOCLIMB`: Do not handle `FF_TRANSLUCENT` and appropriate culling flags like `FF_CUTLEVEL`
* `ML_BOUNCY`: Do not handle collision flags like `FF_SOLID` or `FF_SWIMMABLE`
* `ML_EFFECT1`: No collision during fading ("ghost fade")
* `ML_EFFECT2`: Do not handle lighting or colormaps
* `ML_TFERLINE`: Use exact alpha values in OpenGL instead of the 9 alpha levels from Software
Default behavior is to:
* Handle `FF_EXISTS`: If alpha > 0, force `FF_EXISTS`. Else, remove the flag.
* Handle `FF_TRANSLUCENT`: If alpha < 256, force `FF_TRANSLUCENT`. Else, remove the flag and make opaque.
* Handle collision flags: During the fade routine, set such flags as `FF_SOLID` and `FF_SWIMMABLE` if they were set on spawn. They are unset when reaching the destvalue on a fade out.
* Handle lighting and colormap: They fade out along with the FOF.
* Collision is always set during the fade routine. But, if ghost fade is enabled (`ML_EFFECT1`), collision is turned off during the fade routine. If fading in, it is turned on at end of fade. If fading out, it remains off.
## Type 454: Stop Fading FOF
* `Front X offset`: FOF target sector tag
* `Front Y offset`: FOF control sector tag
* `ML_BLOCKMONSTERS`: Do not finalize fading collision flags; default is to do so.
# Moving platform fix: Player snaps to floor when setting ~FF_EXISTS
When setting ~FF_EXISTS on a moving platform while player stands on it, player immediately snaps to the floor below.
Fixing this required snagging a reference to the FOF that `tmfloorz` refers to -- that's the hard part. Once the reference is collected, just check it for FF_EXISTS before adjusting player's Z in P_ThingHeightClip.
Works in reverse gravity. Intangibles (water, goop, quicksand) are not affected by this bug.
