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.
handling SIGTTIN/OU allows running Doom3 in the background (or even
sending it to the background with Ctrl-Z + bg) by disabling TTY input
(before it would get stuck when run in background without +set in_tty 0,
see #215)
While at it, I also added signal handlers for some common crash signals
(SIGILL, SIGABRT, SIGFPE, SIGSEGV) to print a backtrace before exiting
the game (partly based on Yamagi Quake II code).
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)
Changing idSession would break the interface for Game DLLs, making the
existing ports of Mods incompatible.
Luckily we have idCommon::GetAdditionalFunction() for cases like this..
Also added a check for WEAPON_NETFIRING in idWeapon::EnterCinematic(),
I got an Assert() there in Debug builds.
Running the Demo seems to work now, at least I could finish it without
any problems (ignoring some warnings in the console)
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
WIN_DESKTOP means that this can currently only be set for the top-level
window in a .gui (all its subwindows/widgets will be scaled implicitly)
There are two ways to make a GUI use this:
1. in the .gui add a window variable "scaleto43 1", like
windowDef Desktop {
rect 0 ,0 ,640 ,480
nocursor 1
float talk 0
scaleto43 1
// .. etc rest of windowDef
2. When creating the GUI from C++ code, you can afterwards make the
UserInterface scale to 4:3 like this:
idUserInterface* ui = Whatever(); // create it
ui->SetStateBool("scaleto43", true);
ui->StateChanged(gameLocal.time);
Both lines are important!
As you can see in my changes to Player.cpp, my primary usecase for this
is the cursor/crosshair GUI.
So stuff doesn't look so distorted in widescreen resolutions.
Implies that there are black bars on the left/right then..
Can be disabled with "r_scaleMenusTo43 0"
Does *not* affect the HUD (incl. crosshair) - scaling it automagically
would be very hard (or impossible), because it doesn't only render
the crosshair, healthpoints etc, but also fullscreen effects like the
screen turning red when the player is hit - and fullscreen effects
would look very shitty if they didn't cover the whole screen but had
"empty" bars on left/right.
(Mostly) fixes#188 and #189
Mods that have their own video settings menu can tell dhewm3 to replace
the "choices" and "values" entries in their choiceDef with the
resolutions supported by dhewm3 (and corresponding modes).
So if we add new video modes to dhewm3, they'll automatically appear in
the menu without changing the .gui
To enable this, the mod authors only need to add a "injectResolutions 1"
entry to their resolution choiceDef. By default, the first entry will
be "r_custom*" for r_mode -1, which means "custom resolution, use
r_customWidth and r_customHeight".
If that entry shoud be disabled for the mod, just add another entry:
"injectCustomResolutionMode 0"
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)
if --help or -h or -help or -? or /? is passed as commandline argument,
the help is printed (to stdout) and then the game quits.
The help shows some helpful commandline arguments, including how to
tell the engine where to find the game data, how to set the resolution
and more
If an OpenAL source runs out of samples it transisions into state
AL_STOPPED. That happens if we're entering the menu (which switches
to another soundworld) and when saving the game (because the game
blocks for some milliseconds). Work around this by adding a new
field 'stopped' to the channel state and use that to determine if
a sound was stopped. And not AL_STOPPED like before.
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
so even with many loud sounds the overall volume isn't reduced by
OpenAL - apparently OpenAL scales down all sounds temporarily if the
mixed result would be too loud or sth like that.
Just sending all sounds to OpenAL with a lower volume prevents that from
happening (just set your system speaker volume a bit higher if needed).
This problem was especially noticable when shooting at metal walls with
the shotgun (each pellet produces an impact sound so it gets kinda loud)
