* Blend tables generated by the game.
* The Color Cube accessibility tool.
* Fixed another stupid typo that got in the way of FF_BLENDMASK working.
* Some minor adjustments for code cleanliness.
(side note, it's weird as hell that code we inherited from vanilla next - and i checked, it wasn't mangled in the merge - has bugs that straight up prevent it from functioning properly...)
All my work thus far on solving the drawflag/renderflag/additive/subtractive conundrum.
Outstandng problems:
* Bad additive/subtractive tables means that they appear opaque except under certain conditions.
* No support for FOFs, Polyobjects, or linedefs in OpenGL yet.
* All OpenGL support mostly done blind, may or may not function in practice.
If nothing else, the hard engineering problems are solved and it's just bug hammering...
* Adjust several loading strings, and left-align their rendering.
* Don't call HU_LoadGraphics() again (startup cached ALL FONTS twice).
* Adjust when some functions are called during loading to more effectively compartmentalise sections of loading that depend on each other.
* LOADED_ISTARTUPGRAPHICS now comes after SCR_Startup, as we can explicitly guarantee the palette has been loaded after that function.
* Make sure everything closely related to configurations (gamedata, console stuff, etc) which is not directly dependent on anything else is loaded under LOADED_CONFIG - "Load settings" (formerly LOADED_MINIT).
* The `-warp` command line parameter is now checked alongside LOADED_DCHECKNETGAME.
* Don't attempt to draw the loading bar before LOADED_ISTARTUPGRAPHICS, as the palette is not loaded, which means you're wasting cycles on a white screen.
* Resolves#145.
* Increased granularity, to seperate out texture loading and sprite loading from other render structure initialisation.
* Shows small loading string in DEVELOP builds, to show where we can optimise loading times when we're polishing.
* Clean up con_refresh/startup, which got split into two variables in the merge by mistake.
This fixes slightly raised fofs drawing on top of sprites that should be in
front of them. Previously would check that the bottom of the object was above
the plane. Now also uses sprite offsets like the fof seg sorting does.
Say you have a higher plane in the foreground and a lower one behind. And then
insert a sprite above the plane in the background, the top of which is higher
than the height in the foreground. Should the sprite be drawn in front of the
foreground plane? I think not. Sprites drawing in front of a plane if only part
of them is above the plane is a rendering trick that allows sprites to extend
into the floor. This doesn't make sense if the plane they extend into would be
obscured anyway, or if they don't extend into the plane at all.
This fixes slightly raised fofs drawing on top of sprites that should be in
front of them. Previously would check that the bottom of the object was above
the plane. Now also uses sprite offsets like the fof seg sorting does.
