Fix the nonsense going on here regarding dc_colormap, this makes FOF walls appear strange if they were for a fog block with colormap adjacent to a normal sector with a colormap and no FOFs.

...that was a mouthful

Do lightlist height stepping *after* the heights are used by the FOF rendering code, not before (yes, I caught that they remove a heightstep beforehand for FOFs, but that wasn't done for midtextures it seems?)

Additionally add some macros for repeated slope end assignments and overflow tests

Move shared code here instead of duplicating it for both dc_numlights and non-dc_numlights rendering code

Also added a few comments, and include the out of range check in the "shared code" above

No memory leak here, just a very tiny thing I noticed.

* Fix a memory leak regarding implementation of SOC_ (improperly copypasted code from LUA_LoadLump!!)
* Optimise the repeated strlen usage into a single call, which is stored for later.

Weather is already run client-side. What if we ran it render-side, for major performance gains? This commit will answer all your questions - and more!

A value of 1 in freesrc for Mix_LoadWAV_RW and Mix_LoadMus_RW calls SDL_RWclose on the RWops anyway.
For Mix_LoadWAV_RW the RWops is freed right after the data is loaded (because it makes a copy of the data in memory)
For Mix_LoadMUS_RW the RWops is freed when Mix_FreeMusic is called (because the data is not a copy)
So setting 1 on freesrc doesn't actually free the RWops immediately on Mix_LoadMus_RW *unless* it failed to load any music.

Mix_QuickLoad_RAW sets a flag in the Mix_Chunk so that Mix_FreeChunk doesn't actually Free the sound.
Checks for the flag when freeing, and if it's 0, we free the data manually after Mix_FreeChunk.
I went back to Z_Malloc and Z_Free for this because they still work after this.

Thanks again MonsterIestyn!

R_CreateColormap2 and R_MakeColormaps have been made obsolete, it's just R_CreateColormap now, like it used to be!

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

Introduce a temporary measure to enable the old stuff, minus one of the most obviously terrible bugbears of yesteryear. Let it be known that any downstream poirt will almost certainly toggle this ASAP.

Clean up a bunch of v_video.c functions that previously exhibited unfortunate side effects when run in non-green resolutions.

* 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...

Change the order of operations when applying transparency and colormap such that colormap isn't applied to the screen pixel twice (or, in the case of R_DrawTranslatedTranslucentColumn_8, thrice).

Please note I haven't touched the ASM equivalent, given as it's not actually used.

Quick fix for LJ's password fix: don't check if password is set until we've confirmed that the receiving player is the server!