GetAdditionalFunction() will return a function that returns true
if we're running the Doom3 demo version.
Not really relevant for mods, but I use this to enable some
Demo-specific hacks/workarounds in base.dll
Adding this here anyway to make sure the next function type added will
get another ID (maybe 2).
it could happen that i is 1 but numPlanes is still 0
(=> if for i = 0: ( p[j] - p[i] ).LengthSqr() < 0.01f )
so planes[-1] would be accessed which of course is invalid and can crash
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.
This is an ugly hack that allows both exporting additional functions
(incl. methods via static function + void* userArg) to Game DLLs
and setting callback functions from the Game DLL that the Engine will
call, without breaking the Game API (again after this change).
This is mostly meant for replacing ugly hacks with SourceHook and
similar and mods (yes, this is still an ugly hack, but less ugly).
See the huge comment in Common.h for more information.
Right now the only thing implemented is a Callback for when images
are reloaded (via reloadImages or vid_restart) - Ruiner needs that.
Also increased GAME_API_VERSION to 9, because this breaks the A[PB]I
(hopefully after the next release it won't be broken in the foreseeable
future)
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
Sometimes memory was allocated with new[] but freed with delete instead
of delete[], which is wrong.
And there were some small memory leaks, too.
Furtunately clang's AddressSanitizer detected all that so I could easily
fix it.
(There seem to be some more small memory leaks which are harder to fix,
though)
__builtin_trap() causes an illegal instruction and thus the process
can't resume afterwards.
raise(SIGTRAP) only breaks into the debugger and thus allows to
"ignore" the assertion while debugging.
The assertion in idBounds::operator-(const idBounds&) was triggered
from idWeapon::Event_LaunchProjectiles() (ownerBounds - projBounds)
It only happened when using the BFG.
So I added a check to make sure calling operator- is legal.
I guess this also caused #122
While I couldn't reproduce the crash, according to the bugreport it
happens if renderSystem->GetScreenWidth()/Height() returned 0 - and
that is indeed the only plausible reason I can imagine for it.
So I check for that case and handle it gracefully by defaulting to
4:3 FOV values.
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
