- the gamepad button (or trigger) bound to attack (fire) now always
acts like the left mouse button in menus
- Display correct button name for "Back" button on Playstation-like
gamepads, even depending on whether it's PS3-like ("Select") or
PS4/5-like ("Share")
- Log some more information about detected gamepads
turns out SDL 2.0.12 added SDL_GameControllerGetType() which tells you
what kind of controller it is (xbox, playstation, nintendo, ..).
Using this to implement an auto-mode for joy_gamepadLayout, when it's
set to -1 (the new default).
This should still build with older versions of SDL2 (but won't have
that autodetection then).
The button names shown in the controls menu now depend on this CVar.
So if you set it to 1 (Nintendo), the "A" button (which, based on its
position, would be "B" on XBox/XInput gamepads) is actually shown as
"Pad A", and if it's set to 2 (Playstation), it's shown as "Pad Cross".
The "real" names, used in the config, remain the same and are based on
position: JOY_BTN_SOUTH, JOY_BTN_EAST, JOY_BTN_WEST, JOY_BTN_NORTH
- make moving the cursor more precise by using an exponential curve
for axis value => cursor speed
- emulate cursor keys with DPad and Enter with left trigger
- also use right trigger for leftclick, as it's usually used for firing
a weapon and thus used for "clicking" ingame UIs
- fix hovering/highlighting menu elements when moving cursor
with gamepad
- treat DPad as 4 regular buttons (was already the case mostly, but now
the code is simpler)
- rename in_invertLook to joy_invertLook and in_useJoystick to
in_useGamepad and remove unused CVars
- make controller Start button generate K_ESCAPE events, so it can
always be used to open/close the menu (similar to D3BFG)
- move mousecursor with sticks, A button (south) for left-click,
B button (east) for right-click (doesn't work in PDA yet)
- removed special handling of K_JOY_BTN_* in idWindow::HandleEvent()
by generating fake mouse button events for gamepad A/B
in idUserInterfaceLocal::HandleEvent()
- renamed gamepad/joystick actions and keys to have some meaning
for buttons (instead of just JOY1, JOY2 etc)
- compiles with SDL1.2 again (there gamepads aren't supported though)
- shorter names for gamepad keys/axis in the key bindings menu
Doom3 and RoE can't be bought alone anymore, only as part of D3 BFG,
so link that instead.
Has the advantage of being cheaper, also giving you the BFG edition,
and (presumably?) making RoE available to German users.
(also added a comment in CMakeLists.txt, for mingw32, copy of the
equivalent comment in MSVC section)
Added the ability to change the screenshot format with a new CVar:
r_screenshotFormat. This has four options: 0 (TGA), 1 (BMP), 2 (PNG),
and 3 (JPG). JPG quality can be selected with a new CVar:
r_screenshotJpgQuality. TGA is the default to preserve original behavior
from DOOM 3.
A new dependency on stb_image_write has been added. It has been
included. No additional configuration with CMake is required.
According to
https://cmake.org/cmake/help/v3.26/variable/CMAKE_LANG_COMPILER_ID.html
there's at least "Clang" (plain LLVM clang), "AppleClang", "ARMClang",
"FujitsuClang", "XLClang" and "IBMClang" (both of which are variations
of the clang/llvm-based IBM XL compiler).
This should detect all of them (I hope they all behave close enough
to normal clang to work..)
There's also "IntelLLVM", but I have no idea if that's based on Clang
or does its own thing based on LLVM.. I also doubt dhewm3 will ever
be built with any other clang-derivate than "Clang" and "AppleClang" :-p
fixes#510
in the "Work around false positive GCC -W(maybe-)uninitialized warnings"
commit I changed that code.. but my change made it nonsensical,
of course we must get oldBounds before calling the callback which
changes the bounds, otherwise comparing the "oldbounds" with the
current bounds just compares them with themselves..
afxv_w32.h (apparently included indirectly viw edit_gui_common.h)
complained that windows.h (included indirectly via DebuggerServer.h
-> platform.h) was included first, apparently that's not allowed..
this was broken by the recent "fix mingw build" commit; now hopefully
both work (MinGW doesn't support building the tools, because they need MFC
which only works with MSVC)
The HD version of the "Birdman" Hellknight model crashed the game,
because on Linux it triggered the 600KB _alloca() assertion and on
Windows (that didn't have such an assertion up to this commit) it
overflowed the stack.
Thde default stacksize on Windows is 1MB, increasing that to 8MB fixes the
problem (in Doom3 1.3.1 it was 4MB).
I also implemented the _alloca() size check assertion for Windows, and
increased the allowed size to 2MB (so it can be safely called multiple
times per function)
Model: https://www.moddb.com/mods/birdman-doom3/downloads/birdman-doom3-v11
<intrin.h>, included by SDL_cpuinfo.h via SDL.h, defines strcmp.
If the idlib/Str.h `#define strcmp idStr::Cmp` hack is visible when
that file is parsed, there's a compiler error (because strcmp in
intrin.h is replaced with idStr::Cmp then).
So I reorderedd includes a bit until it compiled again..
this was so broken, I think if anyone ever tried to use __DATE__ or
__TIME__ it must've crashed, either from free(curtime) (which was the
return value of ctime()) or from things like token[7] = NULL when token
was a pointer (to a single element!).
I think it could work now.
Also fixed potential memory leaks in cases that don't "return" anything
or, in the case of AF.cpp, at least comment on them
I think this fixes most of the remaining "interesting" GCC 12 on Linux
warnings, except for some in idParser::ExpandBuiltinDefine() that I'll
fix in the next commit
For some reason MSVCs integrated CMake doesn't set CMAKE_GENERATOR_PLATFORM
so my CPU arch detection magic in CMakeLists.txt didn't work in that case..
Now (when using MSVC) the CPU architecture (D3_ARCH) is set in
neo/sys/platform.h instead.
-DASAN=ON enables the Address Sanitizer (ASan), if supported
-DUBSAN=ON same for Undefined Behavior Sanitizer (UBSan)
-DFORCE_COLORED_OUTPUT=ON forces GCC or Clang to use colors in their
messages, useful when building with ninja
All three options default to OFF (though when building with make in a
suitable terminal, GCC and clang automatically use colors)
Also modified the cmake_minimum_required() line to shut up deprecation
warnings (though TBH I have no idea if this really still works with
CMake 2.6)
Commit 3c01757d27 introduced scaling down all sounds to prevent too
many loud-ish sounds from making OpenAL scale the overall volume down.
The problem is that before this change, many sounds had a volume > 1.0,
but vastly different: e.g. player_machinegun_fire was 5.039685 (14dB)
and player_chaingun_fire was 1.414214 (3dB).
But in the end, all volumes were clamped to 1.0 before setting AL_GAIN
(because AL_GAIN only supports values between 0 and 1 by default), so
the machinegun and chaingun had the same volume after all.
When scaling those down to 1/3 of the original volume, some sounds that
used to have a volume of >= 1.0 (=> AL_GAIN set to 1.0) had a volume
lower than 1.0, so they suddenly the chaingun sounded quiter than
the machinegun. While theoretically this is more correct than before
(after all, the sound shader of player_chaingun_fire set a much lower
volume than that of player_machinegun_fire), it doesn't sound like it
used to (even with the old software sound backend!).
Clamping to 1.0 *before* scaling to 1/3 should restore the old behavior
(of all sounds with volume > 1.0 before clamping using the same AL_GAIN)
while still avoiding the issue of having OpenAL (Soft) scale down the
overall volume when shooting a metal wall with the shotgun.
Unsurprisingly the same problem (inconsistent weapon volumes due to
incorrect sound shaders setting the volume way to high and thus relying
on being clamped to 1.0) that occurred with my volume *= 0.333 hack
also happens when reducing the global volume.
So apply that global volume scale *after* clamping to 1.0
see https://github.com/bibendovsky/eaxefx/pull/28#issuecomment-1367436162
Some entities wrote the handle from gameRenderWorld->AddLightDef()
into savegames and reused it after restoring it.
That's a bad idea, because at that point the handle most likely belongs
to something else (likely some idLight). The most visible issue this
can create is that the flashlight may not work correctly after loading
a savegame with flashlight on, when it happens to alias a light that's
updated each frame to (mostly) being off..
The correct way to handle this (THAT FOR SOME REASON WAS ALREADY
IMPLEMENTED IN D3XP BUT NOT THE BASE GAME - WHY?!) is to get a fresh
handle with AddLightDef() when restoring a savegame - unless the handle
was -1, which means that the light didn't exist when saving.
fixes#495
