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
idClipModel::axis is an idMat3 rotation matrix.
Usually it's an identity matrix, but if the player is pushed around by
an idPush entity it's modified and apparently can (wrongly) remain
modified, possibly when saving while idPush is active.
This seems to happen sometimes on the crashing elevator in game/delta1.
The fix/workaround is to reset it to mat3_identity when loading a
savegame.
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
"Fix "t->c->value.argSize == func->parmTotal" Assertion in Scripts, #303"
had broken old savegames because the script checksum
(idProgram::CalculateChecksum()) changed, see #344.
This is fixed now, also the BUILD_NUMBER is increased so old savegames
can be identified for a workaround.
Don't use this commit without the next one which will further modify the
savegame format (for the new BUILD_NUMBER 1305)
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)
* Windows DLL-Load-Errors
Added error reporting using formatmessage, ignoring if the DLL just
doesn't exist, custom warning for "[193 (0xC1)] is not a valid Win32
application." (probably wrong architecture)
* update gitignore with build folder
.. but only if the file exists.
It's ok if mods don't have their own DLL/.so, but if they do have one
and loading fails it's interesting why they failed (e.g. no access
rights, 64bit lib with 32bit executable or other way around, missing
symbols due to wrong libc version, ...)
The same should be done for Windows, but that's still TODO.
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.
.. that doesn't switch the display resolution, but creates a borderless
fullscreen window at current desktop resolution.
SDL2-only (SDL_WINDOW_FULLSCREEN_DESKTOP).
Doing this with an additional CVar instead of r_fullscreen 2 or similar
has the advantage that it works properly with Alt-Enter
SDL has a bug (at least on Windows) where SDL_CreateWindow() with
SDL_WINDOW_FULLSCREEN doesn't use the configured resolution (if it's
higher than the current desktop resolution).
Try to work around that - based on Yamagi Quake II code.
Also, if GLimp_Init() fails, the "safe mode" fallback is now in
windowed mode instead of fullscreen mode.
The code used #ifdef __ppc__, probably a leftover from old Mac support,
which apparently doesn't work on all PPC systems (maybe not 64bit PPC).
Now using the LittleFloat() function instead which exists for
exactly this purpose and already handles endianess properly.
If a "class" (object) in a Script has multiple member function
prototypes, and one function implementation later calls another before
that is implemented, there was an assertion when the script was parsed
(at map start), because the size of function arguments at the call-site
didn't match what the function expected - because the function hadn't
calculated that size yet, that only happened once its own
implementation was parsed.
Now it's calculated (and stored) when the prototype/declaration is
parsed to prevent this issue, which seems to be kinda common with Mods,
esp. Script-only mods, as the release game DLLs had Assertions disabled.
It corrupted the stack when called with buffers allocated on the stack
and numSamples that are not a multiple of four, apparently, by writing
4 floats too many, at least in the 22KHz Stereo case..
This caused the crash described in
https://github.com/dhewm/dhewm3/issues/303#issuecomment-678809662
Now it just uses the generic C code, like all platforms besides MSVC/x86
already do.
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.
idSessionLocal::SaveGame() uses saveName for both the description in
savegames/bla.txt and the filename itself ("bla" in this case), which
is a "scrubbed" version of that string ("file extension" removed,
problematic chars replaced with '_').
In case of Autosaves, MoveToNewMap() passes a translated name of the
map as saveName, which makes sense for the description, but not so much
for the filename.
In Spanish the Alpha Labs names are like "LAB. ALFA 1", "LAB. ALFA 2" ..
and everything after "LAB" is cut off as a file extension - so every
autosave of an Alpha Labs part overwrites the last one, as they all get
the same name...
The solution is to pass an additional (optional) argument saveFileName
to idSessionLocal::SaveGame(), and for autosaves pass the mapname
(which is the filename without .map; yes, it might contain slashes,
but the scrubber will turn them into _) instead of the translated name
as saveFileName.
If you save, you get a message like "Game Saved..." which goes away
after a few seconds. This happens at the very end of idPlayer::Save():
if ( hud ) {
hud->SetStateString( "message", /* .. left out .. */ );
hud->HandleNamedEvent( "Message" );
}
And handled in hud.gui, "onNamedEvent Message { ..."
However, if you save again before it's gone, it'll be shown after
loading the savegame and not go away until you save again..
This works around that issue by setting an empty message after loading
a savegame.
The underlying problem (which is not fixed!) seems to be that the
transition GUI command (that's executed when hud.gui handles the
"Message" event that's used to show this message) is probably not
properly saved/restored so fading out the message isn't continued
after loading.
idStr::StripFileExtension() (and SetFileExtension() which uses it) and
others didn't work correctly if there was a dot in a directory name,
because they just searched from last to first char for '.', so if the
current filename didn't have an extension to cut off, they'd just cut off
at any other '.' they found.
So D:\dev\doom3.data\base\maps\bla could turn into D:\dev\doom3
(or, for SetFileExtension(), D:\dev\doom3.map)
While at it, I made most of the idStr code that explicitly checked for '\\'
and '/' (and maybe ':' for AROS) use a little "bool isDirSeparator(int c)"
function so we don't have the #ifdefs for different platforms all over
the place.
the game was frozen (the main menu and console worked though) when
switching from the Radiant to the engine (with F2 or that button).
Turned out common->ActivateTool( false ) must be called if the game window
has forcus, so idSessionLocal::Frame() doesn't return early (and thus not
run the game code).
Furthermore, there was no sound when switching from Radiant to the game,
because the SoundWorld was set to sth editor-specific. Fixed that as well.
I worked around the issue for the particle editor, but now it turned out
it can also somehow happen when switching from the Radiant to the Engine
(with F2), so I implemented the "proper" fix of restoring
glConfig.vidWidth/Height, that are overwritten in
RenderSystemLocal::BeginFrame(), in RenderSystemLocal::EndFrame().
That could happen if the searchpath was "" (like the default value of
fs_cdpath ...).
I don't think it could do any damage, but it's confusing (if "developer"
CVar is enabled) and pointless.
It caused lots of "Non-portable: path contains uppercase characters: .."
Warnings, which now also become more readable by adding a newline.
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.
For some reason sounds were only updated/started about every 100ms,
which could lead to delays of up to around 100ms after a sound gets
started (with idSoundEmitterLocal::StartSound()) until OpenAL is finally
told to play the sound.
Also, the actual delay drifted over time between 1ms and 100ms, as the
sound ticks weren't a fixed multiple of the (16ms) gameticks - and the
sound updates didn't even happen at the regular 92-94ms intervals they
should because they run in the async thread which only updates every
16ms...
Because of this, the machine gun and other rapid firing weapons sounded
like they shot in bursts or left out shots occasionally, even though
they don't.
Anyway, now sound is updated every 16ms in the async thread so delays
are <= 16ms and hopefully less noticeable.
You can still get the old behavior with com_asyncSound 2 if you want.
OpenAL devices can disconnect, and with some luck they're back after
a few seconds. This especially seems to happen with Intels Windows GPU
driver and display-audio when switching the resolution or enabling
fullscreen, see #209
Now a disconnect is detected and we try to reset the device for 20
seconds, hoping it comes back. This needs at least openal-soft 1.17.0
to build and 1.20.0 or newer to actually work.
Also added missing stub functions in openal_stub.cpp (used by dedicated
server so it doesn't have to link libopenal)
idSoundSystemLocal::Init() didn't consider the case that opening the
default device (alcOpenDevice(NULL)) could fail, but this can happen if no
audio devices exist (or all are disabled or they're sleeping bluetooth
headphones or whatever).
Starting a map failed then with
ERROR: idSoundCache: error generating OpenAL hardware buffer
Now this and "s_noSound 1" are handled the same and one can play.
If the main sound in a shader was a .wav
(soundShader->entries[0]->hardwareBuffer == true), only that sound was
played (and looped with AL_LOOPING), even if a leadin was configured.
If the main sound was an .ogg it worked.
Not it should always work.
On Windows, ID_INLINE does __forceinline, which is bad if the function
calls alloca() and is called in a loop..
So use just __inline there so the compiler can choose not to inline
(if called in a loop).
This didn't cause actual stack overflows as far as I know, but it could
(and MSVC warns about it).
turns out tri->numIndexes can be quite big so _alloca16() would be
called with >1MB - and the Win32 stack only is 1MB, so that overflows.
As a workaround, use Mem_Alloc16() if we need >600KB
was reported in #265
The Doom3: Lost Mission (aka D3LE) mod uses string table entry keys that
don't follow the proper Doom3 scheme of "#str_01234", but look like
"#str_adil_exis_pda_01_audio_info" - the "hash" algorithm of idLangDict,
which basically just converts the number after "#str_" into an int,
probably doesn't work very well with this and there was an assertion
to prevent this..
However, it seems to work well enough, so now I only print one warning
for the first "invalid" key and otherwise accept those keys.
The stringtable (strings/*.lang) also has font-related entries
(like "#font" "Chainlink_Semi-Bold") that triggered another assertion,
now everything that starts with "#font" is silently skipped.
can be enabled/disabled with the r_useStencilOpSeparate for comparisons
(like Z-Fail, this doesn't really seem to make a difference on my main
machine, neither on my RPi4)
Partly based on Pat Raynor's Code:
2933cb5545/neo/renderer/draw_stencilshadow.cpp
the tables contain character constants like ('ä') that are supposed to
be interpreted as ISO8859-1 or WINDOWS-1252 or sth, but that doesn't
seem to work with MinGW (anymore) - seems like it assumes UTF-8 by
default, and for some reason -finput-charset=ISO8859-1 doesn't help
either, it complains about multichar character constants then..
Anyway, now the table entries are represented as the corresponding
integer constants which seems to work as intended.
Fixes#238
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)
In short, it uses a idGLDrawableMaterial widget that calls
renderSystem->BeginFrame(w, h); (with w and h being small for the texture
preview window) and BeginFrame() sets glConfig.vidWidth and vidHeight to
w/h and that never got reset to the original value (window width/height).
This breaks everything because for some reason
renderSystem->GetSCreenWidth()/Height() return glConfig.vidWidth/Height
so it will just continue to render everything at that resolution (in a
small rectangle on the lower left corner of the window).
This bug has already existed in Doom3 1.3.1 (but was less noticable because
apparently when switching away from Doom3 and back to the window it reset
vidWidth/Height to the window resolution)
I only implemented a workaround (restore glConfig.vid* after rendering the
texture preview), it's possible that the same issue exists in other
(probably editor-) code - but a "proper fix" might also break code (and I'm
not super-familiar with the editor code or even just using them)
When selecting a texture in Inspectors -> Media -> Textures that doesn't
really exist (.mtr defines it, but referenced image files are missing),
the game/editor used to crash.
The problem was that somehow people thought the best way to communicate
that a file wasn't found was by setting the timestamp to 0xFFFFFFFF
and then checking for that - sometimes (incorrectly) by comparing it to -1.
That worked for 32bit ID_TIME_T (typedefed to time_t), but not with 64bit
time_t, which now seems to be the default for Win32 in VS.
So I replaced a few -1 and 0xFF... with FILE_NOT_FOUND_TIMESTAMP and now it
works.
FILE_NOT_FOUND_TIMESTAMP is still defined as 0xFFFFFFFF, maybe I should
change that, unsure if that'd break anything though..
When changing it one should keep in mind that time_t might still be 32bit
on some platforms (Linux x86?) so that should still work.. (-1 could work)
...by including `vecLib/vecLib.h` only on `__APPLE__`, and not just any `__ppc__`
From https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235668:
> On powerpc* platforms vecLib/vecLib.h is included by default.
> This header is only available on Mac OS X, so remove it. It
> doesn't seem to be actually needed to compile this port.
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
