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)
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
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
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)
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
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.
CMAKE_SYSTEM_PROCESSOR used to be broken, CMake "fixed" it by redefining
its meaning (from "Target CPU" to "Host CPU except when crosscompiling").
On Windows it always prints the host CPU, on Linux it at least made trouble
in chroots and when running 64bit kernels with 32bit userlands (this used
to be not totally uncommon on x86 before distros completely switched to
amd64, and apparently Raspbian/Raspberry Pi OS does this on RPi4, see #267)
Thankfully gcc and clang support "-dumpmachine" to print their (default)
target system, so use that instead (MSVC already had a special case).
On the upside, this allows getting rid of the MinGW special case.
I hope this also works with Apple Clang..
set(CMAKE_REQUIRED_LIBRARIES backtrace) tells our custom libbacktrace
availability check that it needs to link against libbacktrace.
Seems like it also tells other unrelated compiler-checks like for
-fvisibility=hidden to link against libbacktrace, so if it's not
available they fail as well.
Fixed by unsetting CMAKE_REQUIRED_LIBRARIES after the backtrace check.
While debian-based distros ship libbacktrace as part of libgcc,
apparently in Arch Linux and openSUSE (and possibly others) it's a
separate package, so I mantion it in the README as an (optional)
dependency now and made CMake print a warning if it's not found.
according to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839
the real compiler flag enabling this bullshit isn't
-fexpensive-optimizations but -ffp-contract=fast which for some(*)
reason is default in optimized builds.
I think it's best to disabled that optimization globally in case it
also breaks other code (I really don't want to spend several days to
hunt such an idiot bug again). I really doubt it makes any measurable
performance difference.
As https://twitter.com/stephentyrone/status/1399424911328874499 says
that clang might also enable this in the future (though to =on instead
of =fast which should be a bit saner but would still break our code),
just set this option for all GCC-ish compilers incl. clang.
(*) the reason of course is that GCC developers don't develop GCC for
their users but to win idiotic SPEC benchmarks
Minimum required Windows version is XP again (instead of Win10).
Win_GetWindowScalingFactor() tries to use two dynamically loaded functions
from newer windows versions (8.1+, Win10 1607+) and has a fallback for
older versions that also seems to work (at least if all displays have
the same DPI).
Moved the function to win_main.cpp so the dynamically loaded functions
can be loaded at startup; so edit_gui_common.cpp could be removed again.
- Upped windows version ( needs to go back, and a runtime dpi check comes in place )
- Changed warning settings for msvc to confirm latest compilers
- Fixed up _afxdll
All pointer<->integer conversion truncation warnings I'm aware of are
now enabled for MSVC, to hopefully finally get that tool code 64bit-clean.
I had to adjust the idCVar code for this - it should've been safe enough
(highly unlikely that a valid pointer is exactly 0xFFFFFFFF on 64bit),
but triggered those warnings - now it should behave the same as before
but the warnings (which are now errors) are silenced.
The only thing that still prevents dhewm3 from building with these
warnings-as-errors is rvGEWindowWrapper
Seems to work; note that idWaveFile is only ever used in idSoundSample::Load()
As stb_vorbis doesn't support custom callbacks for reading, I feed it
the full .ogg files as a buffer. Shouldn't make much of a difference
though - either the whole file is decoded on load anyway (so the buffer
is freed after decoding, or it's streamed, but in that case the old code
also kept the whole ogg file in memory by using idFily_Memory.
I also added warning messages in places where calls to stb_vorbis_*()
can fail, where there were none in the equivalent libvorbis code.
libjpeg is a pain in the ass, especially due to Ubuntu shipping
libjpeg-turbo in jpeg8 mode as their default libjpeg, while every other
distro I checked (including debian!) ships libjpeg-turbo in jpeg6.2 mode
Thankfully stb_image.h exists - just a single header and it even
has a (much!) friendlier API.
It's not like Doom3 (or any of the mods I checked) actually use JPEGs,
but I'm sure if I'd drop support completely, someone would complain
(perhaps rightfully so).
Turns out that ${CMAKE_SYSTEM_PROCESSOR} is broken on Windows
(both for Visual Studio and for 32bit MinGW/msys shells which for some
reason seem to output x86_64 in uname -a)
Also suppressed -Wclass-memaccess warnings from GCC >= 8
like the dhewm3 version and the OS and architecture of the dhewm3
version that created the savegame.
Also added an internalSavegameVersion so be independent of BUILD_NUMBER
fixes#344
This reverts commit 01ac144b09.
Looks like this broke the build on some systems, because some
package managers pack SDL2Config.cmake and others pack sdl2-config.cmake
in their SDL2 development packages (for some reason, SDL2 seems
to ship both in their source, and they appear to be incompatible).
Shipping our own FindSDL2.cmake might be unclean/ugly/whatever, but
at least it works (most of the time? at least it appears to work better
than not shipping it)
I updated sdl2-config.cmake in dhewm3-libs so building on Windows with
them works again, however that required also a little change in
dhewm3's CMakeLists.txt
I also still had some uncommited changes for that fullscreen workaround
that I'm committing now.
Apparently VS2019 (or its integrated CMake?) interpreted
add_definitions(/MP) as "also pass it to rc.exe" which didn't like it..
no idea why this worked before, but now it seems to work everywhere.
fix#304
Also set VS_STARTUP_PROJECT so when launching the debugger in VS it doesn't
try to launch ALL_BUILD (...) but dhewm3.
If REPRODUCIBLE_BUILD is enabled in CMake, the code will not use
__DATE__ or __TIME__ macros, but instead hardcoded values.
Wherever __DATE__ or __TIME__ were previously used, we now use
ID__DATE__ and ID__TIME__, which are either set to hardcoded values or
to __DATE__ and __TIME__ in neo/framework/Licensee.h.
dhewm3 uses source_group(TREE ...) which is only supported in
CMake 3.8 and newer.
As it's only cosmetical (so files show up in correct path in IDEs like
Visual Studio), I just replace the source_group() function with a dummy
for affected CMake versions. At least people can still compile then..
fixes#232
Bringing back support for the (MFC-based Windows-only) editing tools.
Only tested 32bit (not sure if the code is 64bit-clean), needs a
"proper" (non-Express) version of Visual Studio *including* MFC support,
tested the free "Community" Editions of VS 2013 and 2017.
(For VS2013 I needed to install the "Visual C++ MFC MBCS Library for
Visual Studio 2013" because it either didn't include MFC support at all
or only the wrong version, don't remember, you'll need that one anyway)
Upgrade CMakeLists.txt minimum SDK version for compiling in macOS to v.10.9 "Mavericks" for 64 bit builds.
Until now, make failed with this error:
warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
In file included from /Juegos/dhewm3/neo/idlib/bv/Bounds.cpp:29:
/Juegos/dhewm3/neo/sys/platform.h:185:10: fatal error: 'cstddef' file not found
#include <cstddef>
^~~~~~~~~
1 warning and 1 error generated.
Editor also seems to start, didn't test much further.
Only tested 32bit Windows, I fear the editor code isn't 64bit clean..
I hope I haven't broken anything elsewhere..
