This is better be made part of the 2D interface.
That would have been done long ago if it hadn't been for the totally incompatible way this was handled by the purely paletted software renderer.
Now with that out of the way there is no point keeping this code this deeply embedded in the renderer.
Lots of this was still laid out for DirectDraw. This removes most of Begin2D so that it can be done more cleanlz.
Note that this commit renders weapon sprites and screen blends incorrectly. Those will be fixed in an upcoming commit.
- eliminated hqresize.cpp's dependency on GL headers.
- cleaned up the logic for CreateTexBuffer so that hqresize.cpp does not need to check for software warped textures anymore.
- with renderers freely switchable, some shortcuts in the 3D floor code had to be removed, because now the hardware renderer can get FF_THISINSIDE-flagged 3D floors.
- changed handling of attenuated lights in the legacy renderer to be adjusted when being rendered instead of when being spawned. For the software renderer the light needs to retain its original values.
It may use the same calculations as the hardware renderer but must use the 2D drawer for display.
It should be investigated if the hardware renderer can do this as well.
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 also replaces DTA_ColormapStyle with proper implementations of its components. As implemented it was a very awkward mixture of various effects that already existed in a separate form. As a result of its implementation it required additional but completely redundant shader support which could be removed now. As a side effect of this change a new DTA_Desaturate option was added.
No more locking insanity! :)
There are no locking counters or other saveguards here that would complicate the implementation because there's precisely two places where this buffer must be locked - the RenderView functions of the regular and poly SW renderer which cannot be called recursively.
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.
src/v_video.h:56:6: error: ISO C++ forbids forward references to 'enum' types
src/v_video.h:342:17: error: field has incomplete type 'FTextureFormat'
src/v_video.h:344:47: error: variable has incomplete type 'FTextureFormat'
These cannot be done with the regular textures so there needs to be an option to create more than one native texture per FTexture. For completeness' sake there is also the option now to create a paletted version of a texture if the regular one is true color. This fixes a long standing problem that translations were not applied to non-paletted textures.
* store the frame time in the current screen buffer from where all render code can access it.
* replace some uses of I_MSTime with I_FPSTime, because they should not use a per-frame timer. The only one left is the wipe code but even this doesn't look like it needs either a per-frame timer or a timer counting from the start of the playsim.
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.
