- check and use WGL_EXT_swap_control_tear extension. The above change makes the system always wait for a full vsync with a wglSwapInterval of 1, so it now uses the official extension that enables adaptive vsync. Hopefully this also works on the cards where the old setup did not.
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.
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.
After doing some profiling it was very obvious that this has better performance than client arrays. Persistent buffers are still better, though, especially for handling dynamic lights.
- 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.
This eliminates most behavioral differences for FFlatVertexBuffer between both operating modes, now the only difference is where the buffer is located.
Added gl_renderbuffers CVAR that disables render buffers
Added patch shader support to FShaderProgram
Added OpenGL 2 fallback support to render buffers
This reverts commit 616f84209b.
Now I remember why this is not active: This is causing some problems with interpolated plane heights. Since there is no synchronization with the vertex buffer, the next frame will reset all plane coordinates before the GPU can use them. This will require some rethinking about when to update the buffer - it cannot be done in the render data setup loop.
Menu graphics appeared in starting frame with hardware renderer only
Software renderer was not affected as it reads pixels from front buffer instead of back buffer like OpenGL counterpart did
See http://forum.drdteam.org/viewtopic.php?t=6857
GZDoom requires this extension and all supported hardware has drivers implementing it but there still seem to be people out there who stuck to some older, obsolete drivers that don't.
- use sampler objects to avoid creating up to 4 different system textures for one game texture just because of different clamping settings.
- avoids flushing all textures for change of texture filter mode.
- separate sprite and regular dimensions on the material level to have better control over which one gets used. It's now an explicit parameter of ValidateTexture. The main reason for this change is better handling of wall sprites which may not be subjected to such handling.
- create mipmaps based on use case, not texture type.
- allows removal of FCloneTexture hack for proper sharing of the same sprite for decals and other purposes.
- better precaching of skyboxes.
GLEW has two major problems:
- it always includes everything, there is no way to restrict the header to a specific GL version
- it is mostly broken with a core profile and only works if all sanity checks get switched off.
There was one issue preventing the previous 2.0 betas from running under GL 3.x: The lack of persistently mapped buffers.
For the dynamic light buffer today's changes take care of that problem.
For the vertex buffer there is no good workaround but we can use immediate mode render calls instead which have been reinstated.
To handle the current setup, the engine first tries to get a core profile context and checks for presence of GL 4.4 or the GL_ARB_buffer_storage extension.
If this fails the context is deleted again and a compatibility context retrieved which is then used for 'old style' rendering which does work on older GL versions.
This new version does not support GL 3.2 or lower, meaning that Intel GMA 3000 or lower is not supported. The reason for this is that the engine uses a few GL 3.3 features which are not present in the latest Intel driver.
In general the Intel GMA 3000 is far too weak, though, to run the demanding shader of GZDoom 2.x, so this is no real loss. Performance would be far from satisfying.
A command line option '-gl3' exists to force the fallback render path. On my Geforce 550Ti there's approx. 10% performance loss on this path.
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.
- we need to check all GL versions when trying to get a context because some drivers only give us the version we request, leaving out newer features that are not exposed via extension.
- added some status info about uniform blocks.
- reactivate alpha testing per fixed function pipeline
- use the 'modern' way to define clip planes (GL_CLIP_DISTANCE). This is far more portable than the old glClipPlane method and a lot more robust than checking this in the fragment shader.
After thinking about it for a day or so I believe it's the best option to remove all compatibility code because it's a major obstacle for a transition to a core profile.
- disable GL_ARB_buffer_storage when a -glversion parameter less than 4.0 is given. According to the spec this extension requires 4.0 so if emulating something lower it should not be used.
Turns out that the name doesn't accurately describe what it does.
It is correct for images that come with their own palette or are true color.
But for images using the game palette it doesn't use the red channel to determine translucency but the palette index! Ugh...
This means it cannot be done with a simple operation in the shader because it won't get a proper source image. The only solution is to create a separate texture.
