This was done to clean up the license and to ensure that any commercial fork of the engine has to obey the far stricter requirements concerning source distribution. The old license was compatible with GPLv2 whereas combining GPLv2 and LGPLv3 force a license upgrade to GPLv3. The license of code that originates from ZDoomGL has not been changed.
- added colormap shader to postprocessing.
This replaces the in-place application of fullscreen colormaps if renderbuffers are active. This way the fully composed scene gets inverted, not each element on its own which is highly problematic for additively blended things.
That's again one less write access to the buffer. The uniform method was chosen because this way a buffer update can be completely avoided, and setting a single uniform is a lot cheaper and simpler to handle.
- only disable clip planes on Windows, but not on Linux or macOS.
- If a driver reports full OpenGL 4.5 support, assume that all features are working properly.
Added gl_renderbuffers CVAR that disables render buffers
Added patch shader support to FShaderProgram
Added OpenGL 2 fallback support to render buffers
Unfortunately the math behind the old clip planes is utterly impenetrable and so poorly documented that I have no idea how to set that up, so it is deactivated for now. It wasn't working anyway.
- fixed: The shader code for handling special fixed colormaps did not use the color vertex attribute which was most evident with the 'shadow' render style on the spectre.
Sadly, anything else makes no sense.
All the recently made changes live or die, depending on this extension's presence.
Without it, there are major performance issues with the buffer uploads. All of the traditional buffer upload methods are without exception horrendously slow, especially in the context of a Doom engine where frequent small updates are required.
It could be solved with a complete restructuring of the engine, of course, but that's hardly worth the effort, considering it's only for legacy hardware whose market share will inevitably shrink considerably over the next years.
And even then, under the best circumstances I'd still get the same performance as the old immediate mode renderer in GZDoom 1.x and still couldn't implement the additions I'd like to make.
So, since I need to keep GZDoom 1.x around anyway for older GL 2.x hardware, it may as well serve for 3.x hardware, too. It's certainly less work than constantly trying to find workarounds for the older hardware's limitations that cost more time than working on future-proofing the engine.
This new, trimmed down 4.x renderer runs on a core profile configuration and uses persistently mapped buffers for nearly everything that is getting transferred to the GPU. (The global uniforms are still being used as such but they'll be phased out after the first beta release.
