working around CMake (specifically CMAKE_SYSTEM_PROCESSOR) being useless
and related commits ported from dhewm3, up to including
"CMake: Fix typo in MSVC-specific CPU detection for x64"
- (Hopefully) better workaround for miscompiled cross products, #147
(-ffp-contract=off)
- GCC/Clang: Remove -fno-unsafe-math-optimizations
(redundant as long as -ffast-math isn't used)
- Fix runtime assert on PPC OS X
(-mone-byte-bool)
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.
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)
.. with "no trivial copy-assignment".
All the cases I checked were harmless; as long as a class has no vptr
or owns memory (or other resources) that need to be handled properly
in the destructor, memcpy() and memset() aren't too dangerous.
it's only shown in the g_version CVar, but if we have this constant
in the SDK make it show something sensible.. and this SDK code should
be compatible with all dhewm 1.5.x releases (=> dhewm3 version will
be bumped to 1.6.x if game API compatibility is broken)
Also disabled (GCC/Clang-specific) -ffast-math - even with
-fno-unsafe-math-optimizations I don't trust it.
so mod authors can tell cmake to call it mymod.dll instead of base.dll
or d3xp.dll
and the compiler defines are also easily configurable now
I also added a comment to EndLevel.cpp, which was released with the GPL
source (and in d3xp/ it already existed in the SDK), but has not been
used to build the dlls.
I created this repo from the original dhewm3 repo, but I used
git filter-branch to kill all the files that are not needed to just
build base.dll and d3xp.dll (or .so or .dylib or whatever).
So this is basically just the files the original Doom3 SDK had, but
taken from dhewm3 instead (and thus GPL licensed and patched for
64bit-support etc) + some dhewm3 specific stuff + CMakeLists.txt
to build them.
The git filter-branch details:
filter-branch -f --prune-empty --tree-filter /tmp/killkill.sh @
## /tmp/killkill.sh:
#!/bin/sh
find . -exec /tmp/removeothers.sh {} \;
exit 0
## /tmp/removeothers.sh:
#!/bin/bash
FNAME="$1"
if [[ $FNAME == \./\.git* ]] || [[ $FNAME == \./d3xp/* ]] || [[ $FNAME == \./game/* ]]
then
#echo "ignoring $FNAME"
exit 0
fi
if ! grep -Fxq "$FNAME" /tmp/d3sdklist.txt
then
#echo "REMOVING $FNAME"
rm -rf "$FNAME"
fi
exit 0
## /tmp/d3sdklist.txt was is just a textfile with one path per line with
all the files (and directories!) I wanted to keep, like:
.
..
./sys/platform.h
./framework/Game.h
./config.h.in
./CMakeLists.txt
## ... and all the relevant files from the SDK
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
* the OpenAL function definitions mustn't include __declspec(dllimport)
=> fixed by pretending to compile OpenAL statically
* glimp.cpp shouldn't be used in dedicated-only mode (as it was already
the case on Linux and OSX)
=> No special handling for ID_DEDICATED needed in glimp.cpp, as it's not
used anyway
* add APIENTRY to every gl function in stub_gl.cpp for compatibility
with windows headers and MSVC
* remove GL/gl.h #include from win_local.h as it's not needed
* in qgl.h, when building dedicated server for windows, redefine WINGDIAPI
to nothing for SDL_opengl.h #include to get rid off __declspec(dllimport)
by using #pragma push_macro and pop_macro, because our stub is no dll.
Fixes https://github.com/dhewm/dhewm3/issues/39
Set the library name to an empty string to prevent this error:
CMake Error: The following variables are used in this project, but they
are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the
CMake files:
CURL_LIBRARY (ADVANCED)
Never use "game" as library name, use the game name instead. This
allows d3xp/mods to coexist in a single (installation-)directory.
This paves the way for future `make install` or binary installers.
Additionally, the "mods" menu entry works from within the game gui.
