Use > 90 && < 270 instead of >= 90 && <= 270. Fixes a bug where if you fly directly up (flyangle 90) or directly down (flyangle 270), that registers as a backwards direction, so you trigger the loop detection by flying BACKWARDS, not FORWARDS. This edge case (only possible via JUMPTOAXIS) should default to FORWARDS looping.
(cherry picked from commit ce215195f8)
With that, I moved R_CreateColormap2's exclusive software colormap malloc code to R_CreateColormap, and merged the two software-only blocks of code into one. I also disabled any unneeded variables and fixed a preprocessor-related goofup
* V_DrawFixedPatch and ilk:
* Change the offset of V_FLIP so it's not one screen-pixel off where its non-flipped sprite would have started being drawn from.
* Write to x and y as well as desttop so that anti-screen-overflow checks later in the function behave properly with non-green resolutions.
* V_DrawFill:
* Reduce number of operations performed upon `c`.
* V_DrawString and ilk:
* Offset the left and right boundary checks in non-green resolutions such that you can actually draw stuff to the left of basevid screen x coordinate 0.
* Stop orphaning their memory. They ARE PU_LEVEL, so they'll disappear eventually, but, like... it's not good memory management practice to just *orphan* them when you're literally never going to do anything with them ever again. Y'know?
* Make ghosts spawn properly on slopes.
* 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...
