* Changes performed in 0bd460d9e3 didn't take into account xdimenscale and viewingrangerecip like the days of old and this wasn't picked up in d80a32d379 or d80a32d379, where the applied fixes only appeared to work because they worked for me at 2560x1440p.
There are effectively two states - the one in the backend and a local one in the drawer for the render list which is supposed to eliminate some of the more costly repeated calls.
This higher level state was cached globally, which did not work anymore because the real render state could be changed elsewhere without this code realizing it.
All this means that the render list drawer must create a new state cache for each call and also must apply its current pending render state before leaving to ensure that everything is properly reset.
The main reason here is that the scene specific part contains a projection dependent component which would be a problem when transitioning to GZDoom's code. The global viewpoint data already has a field for such a factor so now that gets used.
This also means a significant simplification of the visibility code in Polymost and the removal of several global variables.
Models are inoperable right now anyway so this would never get called, but it does a few things that would cause problems with refactoring the backend code.
Most of what got added is still unused.
# Conflicts:
# source/build/src/palette.cpp
# Conflicts:
# source/build/src/palette.cpp
# Conflicts:
# source/common/engine/i_interface.h
The base palette can be set via .def files so that the engine has no access to it until the entire game state is set up.
This means that font translations and PNG palette remap tables cannot be built when the owning objects are created.
For PNGs this has the added advantage that they only get done when really required and not unconditionally - most of the time the remap table isn't even needed here.
Thid fixes the slider graphics in the option menus.
# Conflicts:
# source/core/gamecontrol.cpp
# Conflicts:
# source/core/gamecontrol.cpp
In the RedNukem frontend this was causing view interpolation glitches, this probably should be disabled a bit more targeted but right now I do not know yet which call causes the problem
