Note that the Strife status bar does not draw the health bars yet. I tried to replace the hacky custom texture with a single fill operation but had to find out that all the coordinate mangling for the status bar is being done deep in the video code. This needs to be fixed before this can be made to work.
Currently this is not usable in mods because they cannot initialize custom status bars yet.
Using I_MSTime is not precise enough, because some camera textures can be done quicker. It was pointless anyway trying to make this multithreading-safe, the entire caching idea here makes no sense if two clippers can simultaneously work on the same level data without changing the memory organization and rendering it ineffective.
src/gl/scene/gl_clipper.h:150:23: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
src/gl/dynlights/gl_aabbtree.cpp:137:24: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:137:34: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:137:44: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:139:6: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:139:30: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:139:54: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:142:6: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:143:3: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:144:3: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_aabbtree.cpp:167:6: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value]
src/gl/dynlights/gl_shadowmap.cpp:163:31: warning: '&&' within '||' [-Wlogical-op-parentheses]
src/p_saveg.cpp:367:16: warning: comparison of integers of different signs: 'unsigned int' and 'int' [-Wsign-compare]
src/p_saveg.cpp:402:60: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
src/p_setup.cpp:1553:39: warning: format specifies type 'ptrdiff_t' (aka 'long') but the argument has type 'int' [-Wformat]
src/scripting/zscript/zcc_compile.cpp:293:74: warning: field 'AST' will be initialized after field 'mVersion' [-Wreorder]
src/swrenderer/drawers/r_thread.cpp:113:21: warning: comparison of integers of different signs: 'int' and 'size_t' (aka 'unsigned long') [-Wsign-compare]
It looks like the memory management at use here is not capable of maintaining multiple instances simultaneously and the camera textures create another scene drawer so the initialization of the main scene drawer has to be delayed until after the camera textures are done.
- replaced TStaticArray with regular TArrays.
They had incomplete implementations preventing proper cleanup of the level loading code. It makes more sense to add the missing methods to the regular TArray and use that.
This also makes some changes to how the game nodes are used to avoid creating a copy: If the head node's pointer is stored in a separate variable, no code needs to check which of the two arrays gets used.
- consolidated the code to calculate a sprite's display angle for all 3 renderers.
As it turned out, they all differed in their feature support because they had always been updated independently by different people.
- moved testcolor and test fades into SWRenderer files.
These CCMDs work by hacking the default colormap and were never implemented for hardware rendering because they require many checks throughout the code.
This has increasingly become an obstacle with the hardware renderer, so now the values are being stored as plain data in the sector, with the software renderer getting the actual color tables when needed. While this is a bit slower than storing the pregenerated colormap, in realistic situations the added time is mostly negligible in the microseconds range.
If we have to write compiler specific code for micro-optimizations I am out.
The Posix compatible version nullified most the advantage on MSVC by writing out the XMM register to memory and then reading back the float.
That's not worth the hassle for an optimization that brings a few microseconds at best.
* dynamic lights also work in the true color software renderer and have been moved out of the OpenGL menu.
* created a separate software renderer menu and moved all relevant options there.
* delete non-applicable options when running in legacy mode.
* moved the OpenGL preferences menu one level up to eliminate a two-entry GL top level menu.
Removing this made me realize that calling the renderers' FakeFlat functions from the automap is inherently unsafe with the recent refactorings because there is absolutely no guarantee that the data may actually still be defined when the automap is being drawn.
So the best approach here is to give the automap its own FakeFlat function that runs independently of render data and assumptions of data preservation. This one can also be a lot simpler because it only needs the floor, not the ceiling info.
- optimized the math to get a plane equation from a linedef. The original code used a generic algorithm that knew nothing about the fact that Doom walls are always perfectly vertical. With this knowledge the plane calculation can be reduced to a lot less code because retrieving the normal is trivial in this special case.
- use the SSE2 rsqrtss instruction to calculate a wall's length, because this is by far the most frequent use of square roots in the GL renderer. So far this is only active on x64, it may be activated on 32 bit later as well, but only after it has been decided if 32 bit builds should be x87 or SSE2.
# Conflicts:
# src/gl/dynlights/gl_dynlight.cpp
# Conflicts:
# src/g_shared/a_dynlightdata.cpp
Since the true color software renderer also handles them there is no point keeping them on the GL side.
This also optimized how they are stored, because we no longer need to be aware of a base engine which doesn't have them.
- removed the LastCamera logic in RenderView. This code predates the first GZDoom release and apparently was only added because back then R_SetupFrame was not fully compatible with the hardware renderer. Today it is not needed anymore.
(Is there anyway to tone down GCC's warning level? It outputs too many false positives for potentially uninitialized variables in which the genuine errors get drowned.)
This one was particularly nasty because Windows also defines a DWORD, but in Windows it is an unsigned long, not an unsigned int so changing types caused type conflicts and not all could be removed.
Those referring to the Windows type have to be kept, fortunately they are mostly in the Win32 directory, with a handful of exceptions elsewhere.
