* Fix that thing where ALL transparent FOF planes were continuously fullbright unless encased in a fog which disables sprite fullbrightness, which was long-hated by many people in the community!
* For backwards compatibility, setting flag 1 in that fog field (which is probably the most common "in-the-wild" usage of this feature) will continue to make objects un-fullbright.
* For situations where you desperately want the behaviour to be enabled, you can apply fog flag 2.
* Change the fadestart and fadeend range in which colormaps are generated.
* The problem HERE was that the darkest light level reached by generated colormaps was actually slightly brighter than the darkest level reached by normal colormaps.
* The typo I fixed does have SOME basis in fact - standard colormap lumps are 34 (33 in 0-indexing) long rather than 32 (31), but whoever wrote this didn't realise that the code for generating them didn't do it DooM style, just bright-to-dark with no extras on the end...
This potentially allows FOFs and polyobjects to display sky flats on them properly, unless skyboxes are involved in which case they'd fail either way
I also updated or added comments to some places of the sky drawing code and related where useful
Recreated my previous code using floats in case the issue was overflowing that could be mitigated using floating point precision - but still doesn't work. Pulling my hair out.
Proper barrel sky distortion
Skies now use proper barrel distortion in both axes, rather than just the x-axis (i.e. just horizontally) as in all previous SRB2 versions. Credit goes to Nev3r for the original change and idea.
Was going to make an option for a non-barrel distorted sky, assuming barrel distortion is the default, but I just can't quite get it to work in a way that is pleasing to the eyes. So I've not bothered with it here for now, unless someone objects to barrel distorted skies for any reason?
See merge request !35
Note: polyobj_t's "translucency" is apparently a SIGNED integer, so in theory it's possible to get polyobj flats to use the "spanfunc = splatfunc" line using negative values. If this is not meant to happen, this should probably be fixed asap
Conflicts:
src/f_wipe.c
Compiling errors fixed in this commit:
* Various cases of mixed declaration and statement code
* Implicit declaration of slope functions (read: you forgot to put "include "p_slopes.h" in MORE than a few places)
* an odd case of a bad fixed_t to float typecase, cause by using P_GetZAt directly inside FIXED_TO_FLOAT
* a few minor cases of bad unsigned-signed comparisons
* no prototypes for some of the new slope functions. For goodness sake Red, this is basic stuff!
These functions were already here before, and I /swear/ the slope
physics became slightly less glitchy after switching to them...
Only issue is the slope plane mapping code hasn't been properly
converted yet, so they don't render properly for now.
