- disable framebuffers for camera textures in legacy mode entirely. This depends on a GL_DEPTH24_STENCIL8 surface which most of these old chipsets do not support, and I really see no point to invest any work here. The worst that can happen is that oversized camera textures won't be processed, which, due to general performance issues, might even be a good thing.
Both of these were inherited from ZDoomGL and in terms of light design in maps it makes absolutely no sense to have them user configurable. They should have been removed 11 years ago.
- restricted gl_lights_additive to legacy code and removed menu entry for this.
For modern hardware this setting is completely pointless, it offers no advantage and degrades visual quality. Its only reason for existence was that drawing additive lights with textures is a lot faster, and that's all it's being used for now.
Added gl_renderbuffers CVAR that disables render buffers
Added patch shader support to FShaderProgram
Added OpenGL 2 fallback support to render buffers
This is to allow easier merging with future ZDoom changes
It was done this way only to avoid having to deal with SVN's poor merging capabilities but with Git this is no longer an issue.
The OpenGL submenus will remain where they are, though.
- avoid rebinding the same texture multiple times, as there's considerable overhead in the texture manager.
- check gl_sort_textures only once per scene, not per draw list.
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.
