This fixes two issues:
* timer related texture animations are not being recreated multiple times if a scene renders multiple viewpoints (e.g. camera textures or portals.)
* interpolation is smoother when maps have a high think time of multiple milliseconds. A good map to see the difference would be ZDCMP2 which has a think time of 4-5 milliseconds. With the timer taken in real time after the thinkers have run and VSync on this resulted in alternating time slices of 11 and 21 ms between frame interpolations instead of an even 16 as should be done for smooth 60 fps because roughly every second frame was offset by those 5 ms.
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)
For some files that had the Doom Source license attached but saw heavy external contributions over the years I added a special note to license all original ZDoom code under BSD.
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.
See https://forum.drdteam.org/viewtopic.php?t=7588
Processing order is now the same as in Chocolate Doom
prBoom+ loads separate files after all WAD lumps though
This makes sense but would change loading sequence existed in ZDoom for years
- activated the RenderOverlay event, now that it can be called from the correct spot, i.e. right after the top level HUD messages are drawn. The system's status output will still be drawn on top of them.
This allows using the UI scale or its own value, like all other scaling values.
In addition there is a choice between preserving equal pixel size or aspect ratio because the squashed non-corrected versions tend to look odd, but since proper scaling requires ununiform pixel sizes it is an option.
- changed how status bar sizes are being handled.
This has to recalculate all scaling and positioning factors, which can cause problems if the drawer leaves with some temporary values that do not reflect the status bar as a whole.
Changed it so that the status bar stores the base values and restores them after drawing is complete.
- better handling of ForceScale for the fullscreen HUD that doesn't mess around with CVARs.
- moved the mug shot into the status bar, because this is global state that needs to be shared between different pieces of code which want to display a mug shot.
- SBARINFO should work off the current status bar settings instead of the ones stored in its script object
- decided to ditch the widget system I had started to lay out. As it turns out that would make things far more complicated and slower than they need to be.
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.
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.
