Commit graph

944 commits

Author SHA1 Message Date
Daniel Gibson
56b3c46ba8 Fix MSVC non-Release builds (_alloca()/assert() didn't play nice) 2023-03-02 18:04:48 +01:00
Daniel Gibson
85a6b3b067
README: Update build instructions for newer versions of VS 2023-02-12 20:09:00 +01:00
James Addison
d57f438db1 Fixup: typo: 'hiehgt' -> 'height' in a few places around the codebase 2023-02-04 19:34:29 +01:00
Daniel Gibson
95d8d75ae0 Update Changelog, another small MD3 fix 2023-01-29 02:46:34 +01:00
Daniel Gibson
604dc7c44d Fix MD3 model support (esp. on 64bit)
.. but even on 32bit it didn't work reliably due to
an uninitialized value
2023-01-29 01:10:41 +01:00
Daniel Gibson
2de8c22f3b Fix MSVC + Tools build
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)
2023-01-21 20:33:14 +01:00
Daniel Gibson
dee76dbb21 Increase stack size on Windows to 8MB, so huge models work
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
2023-01-21 19:26:11 +01:00
Daniel Gibson
e7e06d05f1 Fix SDL1.2 build and type of xthreadInfo::threadId 2023-01-16 03:22:01 +01:00
Daniel Gibson
07985cc5ea Fix MinGW build, #505
<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..
2023-01-16 03:15:21 +01:00
Daniel Gibson
477252308d Fix date/time handling in idParser::ExpandBuiltinDefine()
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
2023-01-05 09:07:04 +01:00
Daniel Gibson
dbe4174c0b Fix/work around other misc. compiler warnings
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
2023-01-05 09:06:34 +01:00
Daniel Gibson
996947eec6 Fix -Wmismatched-new-delete warnings
totally valid, how didn't we find them yet (ok, maybe because those
functions aren't called much)
2023-01-05 07:56:16 +01:00
Daniel Gibson
6730ddcb29 Work around false positive GCC -W(maybe-)uninitialized warnings
shouldn't hurt too much, and the R_IssueEntityDefCallback() code
even is a bit better now
2023-01-05 07:54:41 +01:00
Daniel Gibson
957176d659 Fix GCC -W(maybe-)uninitialized warnings that at least kinda had a point 2023-01-05 07:51:59 +01:00
Daniel Gibson
5844af62ce Don't use "register" keyword, it was deprecated in C++11
.. and even removed in C++17 - and before that it probably didn't do
much in most compilers
2023-01-05 05:07:53 +01:00
Daniel Gibson
279a40a981 Fix -Wformat-security warnings - thanks James Addison!
This is based on https://github.com/dhewm/dhewm3/pull/500
by https://github.com/jayaddison

See also https://github.com/blendogames/quadrilateralcowboy/pull/4
2023-01-05 04:45:34 +01:00
Daniel Gibson
6940d7f678 Fix build with Visual Studio's builtin CMake support
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.
2022-12-31 02:01:52 +01:00
Daniel Gibson
051abc0dd1 Add build instructions for Linux/Ubuntu to README.md
and some other small improvements to the README
2022-12-31 02:01:52 +01:00
Daniel Gibson
a6ba6cb5e5 Add GCC/clang-specific CMake options: ASAN, UBSAN, FORCE_COLORED_OUTPUT
-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)
2022-12-31 02:01:52 +01:00
Daniel Gibson
4567f26539 Fix scaling down volume of all sounds, #179 #326
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
2022-12-31 02:00:30 +01:00
Daniel Gibson
ee4eced60b Fix typo in game/Weapon.cpp from "Fix renderlights ..." commit 2022-12-31 02:00:30 +01:00
Daniel Gibson
a7e4eb8644 Fix renderlights loaded from savegames aliasing other lights
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
2022-11-06 18:12:54 +01:00
Daniel Gibson
2a85b73110 Fix some ubsan warnings 2022-11-06 03:09:05 +01:00
Daniel Gibson
e1e8103982 HARDLINK_GAME option in cmake
to compile game code into executable instead of base.dll/d3xp.dll

allows using UBsan
2022-11-06 03:09:05 +01:00
Daniel Gibson
4dcc7efe59 StartSoundShader() event: special-case for soundName "", refs #494
Some level scripts in d3xp (erebus4, erebus4, phobos2) use
  $entity.startSoundShader( "", SND_CHANNEL_BODY );
(or whatever channel) to stop the sound currently playing there.
With s_playDefaultSound 1 that results in a beep..
Added a special case to that event implementation to call StopSound()
instead when the soundName is "" (or NULL)
2022-10-31 03:20:57 +01:00
Daniel Gibson
d0d00c0095 Bump version to 1.5.3pre
this is not 1.5.2 anymore
2022-10-22 20:57:48 +02:00
Daniel Gibson
177740ca88 Fix crash in Radiant Model Preview Dialog, fix #496
the problem was a double-free on files, because USE_COLLADA is not defined.
I'm not even sure why this USE_COLLADA code exists, as we don't have any
real collada support code anywhere..
2022-10-22 20:47:33 +02:00
PLG
cc0f49f9a8 Remove deprecated warnings on mac for cString use. 2022-07-07 22:47:12 +02:00
Daniel Gibson
2e71b99ee0 dhewm3 1.5.2 2022-06-13 03:36:23 +02:00
Daniel Gibson
89c44d7ac9 Make warning about falling back to base.dll more visible
.. by surrounding it with newlines.
This warning is shown when trying to start a mod without its game dll
(because the user has forgotten to unpack the mod dll archive, or
 because it's a mod that doesn't have its own dll).
Surrounding it with empty lines hopefully makes it easier for users
to figure out what went wrong when they look at the log.
2022-06-08 03:22:12 +02:00
Kevin Degeling
42b37b039e Include Linux metadata based on App Stream standard 2022-06-08 00:53:39 +02:00
Daniel Gibson
a2929d9062 Fix Light Editor in Radiant (#456)
When selecting a light in the Radiant (builtin Windows-only level editor)
and pressing `j`, the light editor opened (as expected) but said that
no entity was selected.
That was because com_editorActive was false, most probably because of
  e8a1eb8b Fix mouse remaining ungrabbed when running map from Radiant
which sets com_editorActive to false (via com->ActivateTool(false)) if
the Radiant window loses focus, which should be the case when opening
the light editor window.

`com_editors & EDITOR_RADIANT` is != 0 as long as the radiant is
running, no matter which window currently has focus, so it works better.
2022-05-30 00:33:16 +02:00
Daniel Gibson
6dfada9af0 Update version to 1.5.2rc2
and add entry to changelog about absolute mouse input etc - this change
was already in RC1 but I forgot to mention it..

and fixed comments for GAME_NAME and ENGINE_VERSION (nowadays dhewm3
uses ENGINE_VERSION for the window title)
2022-05-28 18:06:52 +02:00
Daniel Gibson
860181867a Disable assertion in idSampleDecoderLocal::Decode*(), fix #461
It happened a lot more since
  504b572a Update sounds at ~60Hz instead of ~10Hz, fixes #141
(because then MixLoop() is more likely to be called in the narrow
 timeframe this can happen during level load) but could happen before.
So far I only observed it when starting a new game in Classic Doom 3.
See comment in the change and #461 for more information.
2022-05-28 18:05:49 +02:00
Daniel Gibson
cdbb526a3b Add Doom3: Phobos to list of mods that need d3xp (STILL UNSUPPORTED!)
Hoping that Team Future eventually fulfills their promise of releasing
the source of the highly praised Phobos mod, I'm adding it to the list.

Currently this is not very useful, but when (if) the phobos source
becomes available I at least won't have to do a new dhewm3 release to
support it (but only provide tfphobos.dll/.so/.dylib).
2022-05-25 06:34:04 +02:00
Daniel Gibson
2f92bc268d Support loading The Lost Mission and librecoopd3xp via mods menu
by adding special cases for them that set `fs_game_base d3xp`.
Unfortunately there is no more generic way to do this, as mods have
no way to tell the engine if they need fs_game_base.
2022-05-25 06:17:29 +02:00
Daniel Gibson
b88b99fadb Fix assertion when switching to mod via menu, #458
The assertion that triggered was "assert(iconvDesc == (SDL_iconv_t)-1);"
in Sys_InitInput() - because when loading a mod the window is recreated,
calling Com_ReloadEngine_f() -> idCommonLocal::InitGame()
 -> idCommonLocal::InitRenderSystem() -> idCommonLocal::InitOpenGL()
 -> R_InitOpenGL() -> Sys_InitInput()

Before that Com_ReloadEngine_f() calls commonLocal.ShutdownGame( true );
which calls the equivalent Shutdown() functions - except so far no one
called Sys_ShutdownInput() (which closes iconvDesc and resets it to -1).
Fixed that by making idRenderSystemLocal::ShutdownOpenGL() call it.
2022-05-24 03:33:13 +02:00
Daniel Gibson
77e70b5df7 Add some missing newlines and fix typo in changelog 2022-05-21 06:30:54 +02:00
Daniel Gibson
0f9e066bf6 Fix running script debugger if fs_basepath is used
I don't think fs_cdpath is relevant (anymore? has it ever been?), but
fs_basepath sure is.
2022-05-18 04:22:25 +02:00
Daniel Gibson
e8a1eb8baf Fix mouse remaining ungrabbed when running map from Radiant 2022-05-18 04:01:33 +02:00
Daniel Gibson
a363ab4e31 Update version to 1.5.2rc1
.. and fix a link in the changelog
2022-05-16 17:44:15 +02:00
Daniel Gibson
c22965bf58 Work around assertion in alphalabs4, fix #409
In the savegame from that bugreport, "monster_zsec_shotgun_12" was
lying dead pretty much at its spawn point.
script/map_alphalabs4.script moves those "ride_of_death" platforms
around, and at the end of a cycle teleports "ride_of_death*_parent" back
to its starting position - and the "ride_of_death*" bound to it, which
is a pushing mover, just gets dragged along by the physics code and thus
can collide with that zombie cadaver, which then tries to push it along,
causing that assertion in TestHugeTranslation().
This is a map bug - Doom3 even prints a warning:
 WARNING: script/map_alphalabs4.script(722): Thread
  'map_alphalabs4::RideOfDeathPath': teleported 'ride_of_death2_parent'
  which has the pushing mover 'ride_of_death2' bound to it
So I just disable that assertion for this specific case..
Also moved the assertion behind the corresponding warning, so that gets
printed before the assertion kills the game..

Also a small change to CMakeLists.txt that should make enabling
LINUX_RELEASE_BINS after CMake has already been run without it work
2022-05-16 05:43:47 +02:00
Daniel Gibson
adad73cda7
CMake: Fix typo in MSVC-specific CPU detection for x64 2022-02-27 00:37:31 +01:00
Daniel Gibson
699779e9ca Make window alpha chan opaque on Wayland, fix #426
For some reason Wayland thought it would be clever to be the only
windowing system that (non-optionally) uses the alpha chan of the
window's default OpenGL framebuffer for window transparency.
This always caused glitches with dhewm3, as Doom3 uses that alpha-chan
for blending tricks (with GL_DST_ALPHA) - especially visible in the main
menu or when the flashlight is on.
So far the workaround has been r_waylandcompat which requests an OpenGL
context/visual without alpha chan (0 alpha bits), but that also causes
glitches.
There's an EGL extension that's supposed to fix this issue
(EGL_EXT_present_opaque), and newer SDL2 versions use it (when using
the wayland backend) - but unfortunately the Mesa implementation is
broken (seems to provide a visual without alpha channel even if one was
requested), see https://gitlab.freedesktop.org/mesa/mesa/-/issues/5886
and https://github.com/libsdl-org/SDL/pull/4306#issuecomment-1014770600
for the corresponding SDL2 discussion

To work around this issue, dhewm3 now disables the use of that EGL
extension and (optionally) makes sure the alpha channel is opaque at
the end of the frame.
This behavior is controlled with the r_fillWindowAlphaChan CVar:
If it's 1, this always is done (regardless if wayland is used or not),
if it's 0 it's not done (even on wayland),
if it's -1 (the default) it's only done if the SDL "video driver" is
  wayland (this could be easily enhanced later in case other windowing
  systems have the same issue)

r_waylandcompat has been removed (it never worked properly anyway),
so now the window always has an alpha chan
2022-02-05 16:34:34 +01:00
Daniel Gibson
d09ccb8539 If creating window fails, first try to reduce MSAA level, fix #440
so if someone configured 16x AA on a system that doesn't support it
(like when using AMDs open source driver), 8x will be tried before
falling back to a 640x480 window with no AA at all.
(and then it'll try 4x and then 2x and then no AA at all, and only then
 reducing color depth will start, and even later it'll fall back to
 a small 640x480 window)
2022-01-24 06:00:55 +01:00
Daniel Gibson
815099f833
Changelog: Mention #386
that was an important fix
2022-01-20 14:29:54 +01:00
Daniel Gibson
d34832e4fc Fix Mac build 2022-01-17 15:31:10 +01:00
Daniel Gibson
eff9fd6ac3 GLimp_Init(): Log r_mode and resolution used for creating window 2022-01-16 19:39:35 +01:00
Daniel Gibson
5f3356627e CMake: (Theoretically) support Windows on ARM, try to unify ARM CPU names
I don't have such hardware, so I can't test; I also didn't actually build
dhewm3 (would have to build dependencies for ARM first..), but when
configuring ARM or ARM64 targets for Visual C++ in CMake, that's now
correctly detected in CMake.

Also, now D3_ARCH should always be "arm" for 32bit ARM
and "arm64" for 64bit ARM, also when building with GCC or clang.
2022-01-16 18:17:39 +01:00
Daniel Gibson
67d0b7cf01 dhewm3log.txt for Windows, update changelog
I was lazy and just renamed SDL_win32_main's stdout.txt - but I still
added the dhewm3log-old.txt backup function.

I also renamed Sys_GetHomeDir() to Win_GetHomeDir() as it's Win32-only

On Windows it's in Documents\My Games\dhewm3\dhewm3log.txt
2022-01-16 18:17:39 +01:00