* 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.
* Output from PrintVis() in 9dfd3ddd02 showed resulting global visibility as 0.078125.
* Following 0bd460d9e3, resulting global visibility shown as 0.041667.
* Scaling g_visibility by (8.f / 15.f) (0.533333) restores resulting global visibility to 0.078125.
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.
They depend on a deleted texture not writing to the depth buffer, but other parts in the engine like ROR surfaces depend on them writing a proper depth buffer value, so for now there is a global variable that allows to exclude a single tile from ever getting rendered.
I have no idea why this needs to be different than in EDuke32, but without always clearing the depth buffer before rendering a scene viewpoint the game will glitch like crazy.
It now picks the minimum of the current formula and the one from before June 2017 - the current one was causing problems with sprites in the distance so now the old one is used as an upper bound.
