It may use the same calculations as the hardware renderer but must use the 2D drawer for display.
It should be investigated if the hardware renderer can do this as well.
This was done mainly to reduce the amount of occurences of the word FTexture but it immediately helped detect two small and mostly harmless bugs that were found due to the stricter type checks.
* Instead of using the red channel it now uses the grayscale value. While slower in a few situations, it is also more precise and makes the feature more useful.
* For paletted textures do not use the index as alpha anymore but the actual grayscaled color. This is again to make the feature more consistent and useful.
* To compensate for the above there is now a list of hashes for known alpha textures in patch format, so that they don't get broken.
* IMGZ is now considered a grayscale format. There's only two known textures that use IMGZ for something else than crosshairs and those are explicitly handled.
* several smaller fixes.
* the actual color conversion functions for paletted output are now consolidated in a small number of inlines so that future changes are easier to do.
Note: This hasn't been tested yet and will need further changes in the hardware rendering code. As it is it is not production-ready.
Now it is no longer necessary to provide specially set up textures for rendering shaded decals, they can use any PNG texture now that contains a proper red channel.
Handling of the alPh chunk has been removed as a result as it in no longer needed.
Even though unlikely, this should work as a regular texture because it can be used as such.
As a result of the above, true color generation needs to be done explicitly now.
Until now each subclass of FTexture had to implement the entire span generation itself, presumably so that a few classes can use simpler structures.
This does not work if a texture can have more than one pixel buffer as is needed for alpha textures.
Even though it means that some classes will allocate more data now, it's the only way to do it properly.
In addition this removes a significant amount of mostly redundant code from the texture classes.
- added alpha texture processing to all converted classes
As of now this is not active and not tested.
Note that as part of the conversion even those textures that were working as alphatextures will not look correct until the higher level code gets adjusted.
- a bit of header cleanup.
* moved <zlib.h> and <bzlib.h> from files.h to files_decompress.cpp because they are no longer needed for defining the interface.
* added <functional> to the precompiled header
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]
Now all actors have the same metaclass and therefore it will always be the same size which will finally allow some needed changes to the type system which couldn't be done because it was occasionally necessary to replace tentatively created classes due to size mismatches.
The goal is to get rid of PClassPlayerPawn and PClassInventory so that the old assumption that all actor class descriptors have the same size can be restored
This is important to remove some code that seriously blocks optimization of the type table because that can only be done if types do not need to be replaced.
This was done to ensure it can be properly overridden in scripts without causing problems when called during engine shutdown for the type and symbol objects the VM needs to work and to have the scripted version always run first.
Since the scripted OnDestroy method never calls the native version - the native one is run after the scripted one - this can be simply skipped over during shutdown.
This was used in only 4 places, 3 of which could easily be replaced with a memset, and the fourth, in the Strife status bar, suffering from a pointless performance optimization, rendering the code unreadable - the code spent here per frame is utterly insignificant so clarity should win here.
(cherry picked from commit 12a99c3f3c)
This was used in only 4 places, 3 of which could easily be replaced with a memset, and the fourth, in the Strife status bar, suffering from a pointless performance optimization, rendering the code unreadable - the code spent here per frame is utterly insignificant so clarity should win here.
- Took the opportunity and fixed the logic for the Skull Rod's rain spawner. The old code which was part of the 3D floor submission was unable to work with portals at all. The new approach no longer tries to hide the dead projectile in the ceiling, it leaves it where it is and changes a few flags, so that its z-position can be used as reference to get the actual ceiling. This works for line portals, but for sector portals still requires some changes to sector_t::NextHighestCeilingAt to work, but at least this can be made to work unlike the old code.
- added names for the player-related translations to A_SetTranslation.
- fixed: Failure to resolve a function argument was checked for, too late.
- made the parameter for A_SetTranslation a name instead of a string, because it is more efficient. We do not need full strings here.
Needless to say, this is simply too volatile and would require constant active maintenance, not to mention a huge amount of work up front to get going.
It also hid a nasty problem with the Destroy method. Due to the way the garbage collector works, Destroy cannot be exposed to scripts as-is. It may be called from scripts but it may not be overridden from scripts because the garbage collector can call this function after all data needed for calling a scripted override has already been destroyed because if that data is also being collected there is no guarantee that proper order of destruction is observed. So for now Destroy is just a normal native method to scripted classes
The only reason this even existed was that ZDoom's original VC projects used __fastcall. The CMake generated project do not, they stick to __cdecl.
Since no performance gain can be seen by using __fastcall the best course of action is to just remove all traces of it from the source and forget that it ever existed.
