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..
causes trouble on macOS, and we shouldn't interact with X11 directly
anyway, because SDL does it for us.
OpenBSD apparently needed it (at least it was added for OpenBSD
support), but the only place I can imagine it being needed is the
superfluous #include <SDL_syswm.h> in neo/sys/glimp.cpp - which I now
removed. In case it's needed after all please tell me, then I'll add it
again - but guarded by if(os STREQUALS "OpenBSD") or however one checks
for OpenBSD in CMake.
For some reason CMake thinks it's a great default to display all the source
files of a project in Visual Studio as a flat list (instead of in the
directory structure they're physically in).
source_group(TREE ...) *per project/"target"* helps.
Also, so far there was no reason to list or otherwise use header files
in CMakeLists.txt - but for them to turn up in VS they must be added to
the source lists. I've done that, but I'm sloppily globbing them instead
of adding each headder manually like it's done for the source files
(because it doesn't matter if a header that's not really used turns up
in those lists)
In the last few weeks I've played again through the game and kept an eye
on small oddities. And there're a lot of them. For example some GUIs and
videos getting stuck after the first frame (issue #192) or being unable
to protect the guy with the lamp in Alpha Labs 3. Some digging proved
that most - if not all - of these problems are caused by the compilers
optimization level. When build with -O2 both g++ 8.1 and clang 6.0.0 are
producing working code. g++ 8.1 with -O3 has some small, hard to notice
oddities, clang 6.0.0 with -O3 shows a lot of them. Since there's not
measurable difference between -O3 and -O2 just go down to the later:
x doom_o3.txt
+ doom_o2.txt
+----------------------------------------------------------------------+
| + |
| + * |
|x * x * |
| |_____________________|___A______M__A_________M___|_||
+----------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 5 173 178 177 176.4 2.0736441
+ 5 176 178 178 177.2 1.0954451
The version will be 1.4.0 because it's not compatible with
Doom3 1.3.1 mod DLLs.
(Note that this commit doesn't mean 1.4.0 is done, I might do some
minor changes before tagging the Release!)
Because Debian Squeeze's libjpeg6 didn't have jpeg_mem_src(), we added
jpeg_memory_src() to provide the functionality.
This shouldn't be needed anymore and without it we can drop libjpeg code
from our repo.
Fixes#110
The implementation is now in framework/minizip/*
instead of framework/Unzip.cpp
This was version 0.15beta, now we use 1.1 from
zlib 1.2.7/contrib/minizip
Some code had to be adjusted for this, but it got
cleaner on the way
