only override cmd->viewDef in RB_DrawView() if we're drawing the
primary view (which for several calculations before actual drawing
was set to the saved/locked render view)
Note that r_lockSurfaces is more useful with r_useScissor 0 (otherwise
there's black bars over the screen when moving) and r_shadows 0 (otherwise
areas that weren't visible when locking are black because the lights
there are skipped)
remaining bug: gui surfaces move around the screen when looking around
set(CMAKE_REQUIRED_LIBRARIES backtrace) tells our custom libbacktrace
availability check that it needs to link against libbacktrace.
Seems like it also tells other unrelated compiler-checks like for
-fvisibility=hidden to link against libbacktrace, so if it's not
available they fail as well.
Fixed by unsetting CMAKE_REQUIRED_LIBRARIES after the backtrace check.
While debian-based distros ship libbacktrace as part of libgcc,
apparently in Arch Linux and openSUSE (and possibly others) it's a
separate package, so I mantion it in the README as an (optional)
dependency now and made CMake print a warning if it's not found.
according to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100839
the real compiler flag enabling this bullshit isn't
-fexpensive-optimizations but -ffp-contract=fast which for some(*)
reason is default in optimized builds.
I think it's best to disabled that optimization globally in case it
also breaks other code (I really don't want to spend several days to
hunt such an idiot bug again). I really doubt it makes any measurable
performance difference.
As https://twitter.com/stephentyrone/status/1399424911328874499 says
that clang might also enable this in the future (though to =on instead
of =fast which should be a bit saner but would still break our code),
just set this option for all GCC-ish compilers incl. clang.
(*) the reason of course is that GCC developers don't develop GCC for
their users but to win idiotic SPEC benchmarks
Only happend if `ONATIVE` was enabled (or some other flag was set
that enables the FMA extension), the root cause was that the cross
product didn't return 0 when it should, but a small value < 0.
Caused some faces to be missing in maps compiled with dmap.
https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/436#issuecomment-851061826
has lots of explanation.
I think this is a compiler bug, this commit works around it.
fixes#147
I'm gonna use it with libbacktrace - I'll need the path of the
executable before I can use idStr (and thus before I could call
Sys_GetPath(PATH_EXE, str)).
The problem was that the editors called ChoosePixelFormat() instead of
wglChoosePixelFormatARB() - and the normal ChoosePixelFormat() has no
attribute for MSAA, so if MSAA is enabled (by SDL2 which calls the wgl
variant), ChoosePixelFormat() will return an incomaptible format and
the editors don't get a working OpenGL context.
So I wrote a wrapper around ChoosePixelFormat() that calls the wgl variant
if available, and all the necessary plumbing around that.
While at it, removed the unused qwgl*PixelFormat function pointers and
supressed the "inconsistent dll linkage" warnings for the gl stubs
Minimum required Windows version is XP again (instead of Win10).
Win_GetWindowScalingFactor() tries to use two dynamically loaded functions
from newer windows versions (8.1+, Win10 1607+) and has a fallback for
older versions that also seems to work (at least if all displays have
the same DPI).
Moved the function to win_main.cpp so the dynamically loaded functions
can be loaded at startup; so edit_gui_common.cpp could be removed again.
- Upped windows version ( needs to go back, and a runtime dpi check comes in place )
- Changed warning settings for msvc to confirm latest compilers
- Fixed up _afxdll
In idDeclManagerLocal::CreateNewDecl() decl->self->DefaultDefinition();
crashed because self was uninitialized.
Now it gets set to NULL in the constructor and initialized to something
sensible in decl->AllocateSelf();
this is part of #378
it wants to store a pointer to itself in an idWinVar - on 32bit idWinInt
was suitable for that, on 64bit it's not, so instead convert the pointer
to a hex-string and stuff it in a idWinStr
also fix a crash when adding a choiceDef in the gui editor
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.
The only thing that still prevents dhewm3 from building with these
warnings-as-errors is rvGEWindowWrapper
rvGEWindowWrapper is still TODO - it's not as straightforward, because
it insists on storing a pointer in an idWinVar (using idWinInt), but there
is no idWinVar type for pointers
the commented out code clamped the loaded filesize of affected .dds
images (crash observed with dds/guis/assets/splash/pdtempa.dds) to
200KB - but then later tries to load it and skip the first mipmap,
resuling in reading invalid memory (> 200KB into the file).
No idea what this was supposed to achieve, but it's disabled now
and the crash (at startup) is gone.
fixes#374
It can be set to a value between 0.0 and 1.0.
1.0 sounds like it did before introducing this cvar; as many people
found the the effect way to strong, I made 0.5 the default value
Otherwise especially looped sounds continue playing while the menu
is open, especially noticeable when opening the menu while firing
the chaingun (the whirring sound continues playing).
The code to decompress OGG files directly on load if they're shorter
than s_decompressionLimit seconds (usually 6) accidentally got broken
when removing the non-OpenAL soundbackends:
`if ( objectInfo.wFormatTag == WAVE_FORMAT_TAG_OGG )` slipped into the
`if ( objectInfo.wFormatTag == WAVE_FORMAT_TAG_PCM )` block - obviously
both can't be true at the same time so the OGG case was never executed.
Now it's in its own block again. I put it into a {} scope so it doesn't
have to be re-indented (=> more useful with git blame)
Seems to work; note that idWaveFile is only ever used in idSoundSample::Load()
As stb_vorbis doesn't support custom callbacks for reading, I feed it
the full .ogg files as a buffer. Shouldn't make much of a difference
though - either the whole file is decoded on load anyway (so the buffer
is freed after decoding, or it's streamed, but in that case the old code
also kept the whole ogg file in memory by using idFily_Memory.
I also added warning messages in places where calls to stb_vorbis_*()
can fail, where there were none in the equivalent libvorbis code.
libjpeg is a pain in the ass, especially due to Ubuntu shipping
libjpeg-turbo in jpeg8 mode as their default libjpeg, while every other
distro I checked (including debian!) ships libjpeg-turbo in jpeg6.2 mode
Thankfully stb_image.h exists - just a single header and it even
has a (much!) friendlier API.
It's not like Doom3 (or any of the mods I checked) actually use JPEGs,
but I'm sure if I'd drop support completely, someone would complain
(perhaps rightfully so).
the problem was that the sources were still associated to it, because
they get deleted after the listenerSlot: the sources get freed in
idSoundSystemLocal::Shutdown() which is called by
idCommonLocal::ShutdownGame() in line 3217,
while the listenerSlot is deleted via idSessionLocal::Shutdown()
-> delete sw/rw -> idSoundWorldLocal::~idSoundWorldLocal()
-> idSoundWorldLocal::Shutdown() - and idSessionLocal::Shutdown() is
called in idCommonLocal::ShutdownGame() line 3211, before the other.
I'm not gonna mess with the order of deleting things in ShutdownGame(),
but it's sufficient to unassociate the effect slot from the source
when destroying the emitters in idSoundWorldLocal::Shutdown(),
by adding a call for that to idSoundChannel::ALStop() - and destroying
the emitters before deleting listenerSlot.
Before this fix, with ALSOFT_LOGLEVEL=3 you got the following warning:
(WW) Error generated on context 0x5578fce2a280, code 0xa004,
"Deleting in-use effect slot 1"
Thanks for openal-soft's KittyCat for pointing this out!
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)
