This does not work with a setup where the same backend is driving both renderers.
Most of this is now routed through 'screen', and the decision between renderers has to be made inside the actual render functions.
The software renderer is still driven by a thin opaque interface to keep it mostly an isolated module.
This theoretically means that the software renderer could access this data as well - if it just had been written with a more flexible texture interface.
However, as things stand, this may require quite a bit of work to achieve.
The old organization made sense when ZDoom still was a thing but now it'd be better if all pure data with no dependence on renderer implementation details was moved out.
A separation between GL2 and GL3+4 renderers looks to be inevitable and the more data is out of the renderer when that happens, the better.
In its current form this is quite useless. What's really needed is to require a lock on the RenderBuffer for the 3D scene, but since this is not needed for the 2D stuff anymore it can be done far simpler.
This was a bad idea from the start and really only made sense with DirectDraw.
These days a FrameBuffer represents an abstract hardware canvas that shares nothing with a software canvas so having these classes linked together makes things needlessly complicated.
The software render buffer is now a canvas object owned by the FrameBuffer.
Note that this commit deactivates a few things in the software renderer, but from the looks of it none of those will be needed anymore if we set OpenGL 2 as minimum target.
I have no idea why they were even in there, as they intentionally circumvented all GC related features - they declared themselves fixed if prone to getting collected, they all used OF_YesReallyDelete when destroying themselves and they never used any of the object creation or RTTI features, aside from a single assert in V_Init2.
Essentially they were a drag on the system and OF_YesReallyDelete was effectively added just to deal with the canvases which were DObjects but not supposed to behave like them in the first place.
Currently this is only being used for draw operations that are not automap related, i.e. DrawLine, DrawPixel and FillSimplePoly are not subjected to it.
- moved testcolor and test fades into SWRenderer files.
These CCMDs work by hacking the default colormap and were never implemented for hardware rendering because they require many checks throughout the code.
This has increasingly become an obstacle with the hardware renderer, so now the values are being stored as plain data in the sector, with the software renderer getting the actual color tables when needed. While this is a bit slower than storing the pregenerated colormap, in realistic situations the added time is mostly negligible in the microseconds range.
- removed the LastCamera logic in RenderView. This code predates the first GZDoom release and apparently was only added because back then R_SetupFrame was not fully compatible with the hardware renderer. Today it is not needed anymore.
