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.
Added gl_renderbuffers CVAR that disables render buffers
Added patch shader support to FShaderProgram
Added OpenGL 2 fallback support to render buffers
This fixes some jerkiness with vertical scrollers due to a bad sine period and makes the overall appearance of the effect what it was originally supposed to be. The old warp2 shader was not created by replicating the formula but by trial and error until it looked close enough.
A version of the old warp2 shader with a fixed sine period is still available as a custom hardware shader.
* disable the dynamic light code if no buffers are available
* added a duplicate of the getTexel function which cannot be patched without creating syntax problems.
* fixe int<->float conversion warning, which on some compilers may be an error.
- 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.
- 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.
Due to the way the engine works it needs to render a lot of small primitives with frequent state changes.
But due to the performance of buffer uploads it is impossible to upload each primitive's vertices to a buffer separately because buffer uploads nearly always stall the GPU.
On the other hand, in order to reduce the amount of buffer uploads all the necessary state changes would have to be saved in an array until they can finally be used. This method also imposed an unacceptable overhead.
Fortunately, uploading uniform arrays is very fast and doesn't cause GPU stalls, so now the engine puts the vertex data per primitive into a uniform array and uses a static vertex buffer to index the array in the vertex shader.
This method offers the same performance as immediate mode but only uses core profile features.
- Also fixed some very strange thing in the shader's desaturate function. For unknown reasons using the 'mix' function there did not work.
- fixed: The fog boundary special shader could 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.
- remove thing color from lighting calculations.
- implement alpha textures and inverse sprites for infrared as texture modes. This still requires some handling for the alpha texture mode for non-shader rendering because there is no way in the fixed pipeline to do it. The inverted texture effect can be done with a texture combiner.
- fixed: ThingColor for sprites was set in the wrong place. It must be in the Process function, not in the lighting calculation.
- added functions for isolated calculation of sprites' dynlight color.
