This code was written under the assumption that the glGenerateMipmap function does not exist. But all supported hardware has this function through the GL_EXT_framebuffer_object extension.
Now it's the initial check with the adjustment in mode indices only, as old hqNx MMX indices (4..6) are now occupied by generic hqNx implementation
See http://forum.drdteam.org/viewtopic.php?t=6872
The original broken code had it always reset the translucency info to 'not present'.
The first fix completely removed that line, although it was merely misplaced, but still necessary to avoid constant re-checking of the same texture.
- fixed: Textures which are already scaled should not be upsampled.
- fixed: The transparency check in the upscaling code checked the wrong modes for exclusion when handling translucent textures.
- fixed: The 'may not be expanded' state should be stored in the texture and reused later. This also needs to revalidate the material if it decides that expansion should be disallowed.
- In order to get reliable results the empty border around scaled sprites must be the same scale as the sprite (i.e. 2 pixels for 2x scale and 4 pixels for 4x scale.)
- 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.
- 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.
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.
