src/p_pspr.cpp:363:37: warning: more '%' conversions than data arguments [-Wformat]
src/gl/textures/gl_texture.cpp:845:21: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
- added a few access functions for FActorInfo variables.
With PClassActor now empty the class descriptors can finally be converted back to static data outside the class hierarchy, like they were before the scripting merge, and untangle the game data from VM internals.
Both files can now be included independently without causing problems.
This also required moving some inline functions into separate files and splitting off the GC definitions from dobject.h to ensure that r_defs does not need to pull in any part of the object hierarchy.
Most of those which still rely on ZDoom's own definition should be gone, unfortunately the code in files that include Windows headers is a gigantic mess with DWORDs being longs there intead of ints, so this needs to be done with care. DWORD should only remain where the Windows type is actually wanted.
First, if it has already been determined the value should be left alone and second, for translated textures the generated buffer is inconclusive so in that case it cannot be used at all.
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.
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.
- 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.
