41cfd224f9
turns out that __builtin_alloca_with_align() might releases the allocated memory at the end of the block it was allocated in, instead of the end of the function (which is the behavior of regular alloca() and __builtin_alloca()): "The lifetime of the allocated object ends at the end of the block in which the function was called. The allocated storage is released no later than just before the calling function returns to its caller, but may be released at the end of the block in which the function was called." https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005falloca_005fwith_005falign Clang also supports __builtin_alloca_with_align(), but always releases the memory at the end of the function. And it seems that newer GCC versions also tend to release it at the end of the function, but GCC 4.7.2 (that I use for the official Linux release binaries) didn't, and that caused weird graphical glitches. But as I don't want to rely on newer GCC versions behaving like this (and the documentation explicitly says that it *may* be released at the end of the block, but will definitely be released at the end of the function), I removed all usage of __builtin_alloca_with_align(). (Side-Note: GCC only started documenting the behavior of __builtin_alloca and __builtin_alloca_with_align at all with GCC 6.1.0) |
||
|---|---|---|
| cm | ||
| d3xp | ||
| framework | ||
| game | ||
| idlib | ||
| MayaImport | ||
| renderer | ||
| sound | ||
| sys | ||
| tools/compilers/aas | ||
| ui | ||
| .gitignore | ||
| CMakeLists.txt | ||
| config.h.in | ||
| COPYING.txt | ||
| README.md | ||
Fitz Packerton
This is the source of the "Fitz Packerton" game by Brendon Chung, Teddy Dief, Ryan Cousins and Sarah Elmaleh, ported to the dhewm3 SDK.
The original source can be downloaded at http://blendogames.com/older.htm
Fitz Packerton is "A theatrical game about a man and the things he carries. Pack what you must. Pray you won't need it."
You can get the game at https://teddydief.itch.io/fitz
Fitz Packerton is actually an (experimental, short) standalone game, so you don't even need the Doom3 gamedata to run it, only the Fitz data linked above.
you could start it with
./dhewm3 +set fs_basepath /path/to/fitzpackerton/ +set fs_game fitz
How to build
(I should eventually expand this, especially for Windows)
On Linux and similar the following should work (if you have cmake, make and GCC/g++ installed):
- Clone the dhewm3-sdk git repo
- switch to your git clone's directory:
cd dhewm3-sdk - (optional: switch to an existing mods branch:
git checkout dentonmod) - create a build directory:
mkdir build - switch to build directory:
cd build - create Makefile with CMake:
cmake .. - compile the mod .so:
make -j4 - it (e.g.
fitz.so) should now be in the build/ directory, copy it to your dhewm3 install, where base.so and d3xp.so are - start the game with that mod, like
dhewm3 +set fs_game fitz
(Make sure to actually have the mods game data in the right directory as well; the directory name should be the same as the game lib name, but without .so/.dylib/.dll, for example dentonmod/ for dentonmod.so)
On Windows it should be kinda similar, but you have to tell CMake to create a Visual Studio solution for the VS version you're using, or Makefiles for MinGW-w64 or whatever.