It's not advisable to rely on atexit() to invoke SDL_Quit(), as it
causes a segmentation fault on exit for the SDL2 KMSDRM driver due to
a conflict with the Mesa drivers* which upstream Mesa may not elect to fix.
The issue can be resolved by replacing the atexit() call with a signal
handler that will interrupt the D_DoomMain() and D_DoomLoop()
functions, then invoke call_terms() within the main thread before exiting.
We can leave the atexit() hook intact to handle edge cases such as abnormal
process exit, or exit methods which do not produce signals such as Alt+F4 or
window close via GUI (neither of which are possible in a KMS context, so
should not affect KMSDRM sessions).
Fixes a segmentation fault/uninterruptible application hang on exit
for all KMS targets, including Raspberry Pi 4B, 3B and Intel i965.
* See: https://bugzilla.libsdl.org/show_bug.cgi?id=4530 and
https://lists.freedesktop.org/archives/mesa-users/2019-March/001519.html
This was always used with 'consoleplayer' which really is the only thing making sense here. But this is a part of the global state which should be avoided in play code.
In particular, this makes no real sense in case of secondary maps where it should always return false.
# Conflicts:
# src/fragglescript/t_func.cpp
# src/g_inventory/a_keys.cpp
# src/p_acs.cpp
# src/p_mobj.cpp
# src/p_user.cpp
# src/r_data/r_interpolate.cpp
# src/r_data/r_interpolate.h
They are attached and actived explicitly during usual actor initialization sequence
Postponed processing applicable to so called user dynamic lights must be skipped for them
RECREATELIGHTS flag handling for dynamic light actors had the opposite effect of deactivating them
https://forum.zdoom.org/viewtopic.php?t=65683
Rationale:
When a mod adds a custom option menu, it adds a space before it, like this:
```
AddOptionMenu OptionsMenu
{
StaticText ""
Submenu "$MYTITLE", MyOptions
}
```
to prevent custom option menu being in the same block as the last entries in the
standard options list. It's okay.
But when more than one such mod is loaded, each one of them adds a space before
their option menu entry, and Options Menu becomes unnecessary bloated.
This simple edit allows mods to not add a space, still be separated from
standard options.
It's an optional extension of deprecated keyword:
deprecated("2.4", "use ModernFunction instead") int OldFunction();
deprecated("3.5", "use ModernVariable instead") int OldVariable;
Usage of such members will produce the following report:
Script warning, ":zscript.txt" line 123:
Accessing deprecated function OldFunction - deprecated since 2.4.0, use ModernFunction instead
Script warning, ":zscript.txt" line 456:
Accessing deprecated member variable OldVariable - deprecated since 3.5.0, use ModernVariable instead
# Conflicts:
# src/scripting/zscript/zcc_compile.cpp
With `crosshairhealth 2`, the crosshair will now
go from white to yellow, then yellow to red as the player's health
decreases. As the player's health increases up to 200, the crosshair
will also go from white to green to indicate overheal.
This is similar to the implementation in games like Xonotic.
The old behavior (`crosshairhealth 1`) is still the default.
