As nice as the automatic is, this will trigger far too many cases where it will disable translucency for mods that only change some texts. Dehacked is very often only used for non-actor related modifications.
If the automatic is supposed to be the default it needs to do a lot more thorough checks to avoid bug reports due to misunderstanding the feature.
It now works the following way:
(0) - Force off (ZDoom defaults)
(1) - Force on (Doom defaults)
(2) - Auto off (Prefer ZDoom defaults - if DEHACKED is detected with no ZSCRIPT it will turn on) (default)
(3) - Auto on (Prefer Doom defaults - if DECORATE is detected with no ZSCRIPT it will turn off)
This was very poorly done without ever addressing the issues a composite render style can bring, it merely dealt with the known legacy render styles.
The same, identical code was also present in two different places.
The oversight that AlterWeaponSprite overrode even forced styles was also fixed.
OpenGL is not implemented yet but with the problems eliminated should be doable now.
This is to ensure that the Class pointer can be set right on creation. ZDoom had always depended on handling this lazily which poses some problems for the VM.
So now there is a variadic Create<classtype> function taking care of that, but to ensure that it gets used, direct access to the new operator has been blocked.
This also neccessitated making DArgs a regular object because they get created before the type system is up. Since the few uses of DArgs are easily controllable this wasn't a big issue.
- did a bit of optimization on the bots' decision making whether to pick up a health item or not.
- 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.
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.
This addresses the main issue with TObjPtr, namely that using it required pulling in the entire class hierarchy in basic headers like r_defs which polluted nearly every single source file in the project.
src/r_data/sprites.cpp:805:79: error: cannot pass non-trivial object of type 'FString' to variadic function; expected type from format string was 'char *' [-Wnon-pod-varargs]
