Some level scripts in d3xp (erebus4, erebus4, phobos2) use
$entity.startSoundShader( "", SND_CHANNEL_BODY );
(or whatever channel) to stop the sound currently playing there.
With s_playDefaultSound 1 that results in a beep..
Added a special case to that event implementation to call StopSound()
instead when the soundName is "" (or NULL)
- TestHugeTranslation() prints positions (and asserts only afterwards),
from "Work around assertion in alphalabs4, fix#409"
- idCompiler::CompileFile() prints proper filename
from "Fix usage of invalid pointer in idCompiler::CompileFile()"
These are now used by idStr::(v)snPrintf(), and in the future can
be used if a (v)snprintf() that's guaranteed not to call
common->Warning() or similar is needed (e.g. used during early startup)
idStr is used in both the main thread and the async sound thread, so
it should better be thread-safe.. idDynamicBlockAlloc is not.
Use realloc() and free() instead.
For some reason this caused a lot more crashes (due to inconsistencies
in the allocator's heap) with newer Linux distros (like XUbuntu 20.04)
and when using GCC9, while they rarely reproduced with GCC7 or on
XUbuntu 18.04
fixes#391
The only change really is adding SE_MOUSE_ABS to sysEventType_t.
In theory this breaks the ABI, but in practice I don't think mods use
sysEventType_t, and certainly not the ones above SE_MOUSE
(SE_JOYSTICK_AXIS doesn't make sense as Doom3 never supported Joysticks,
SE_CONSOLE is for input from TTY or whatever, and doesn't make sense
for mods to use in any way)
The change in Stub_SDL_endian.h is just me being paranoid.
(side-note: it *might* make sense to replace all that inline-asm in
Stub_SDL_endian.h with compiler intrinsics like GCC/clangs
__builtin_bswap* and MSVCs _byteswap_* - if they are supported in
all relevant compiler versions. GCC supports 32 and 64 bit swaps since
4.3, 16bit since 4.8 and 128bit since 11.x; clang supports 32 and
64 bit swaps at least since 3.0 and 16bit swaps since 3.2;
VS introduced _byteswap_ushort, .._ulong and .._uint64 in VS2003)
working around CMake (specifically CMAKE_SYSTEM_PROCESSOR) being useless
and related commits ported from dhewm3, up to including
"CMake: Fix typo in MSVC-specific CPU detection for x64"
- (Hopefully) better workaround for miscompiled cross products, #147
(-ffp-contract=off)
- GCC/Clang: Remove -fno-unsafe-math-optimizations
(redundant as long as -ffast-math isn't used)
- Fix runtime assert on PPC OS X
(-mone-byte-bool)
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.
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)
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)
.. with "no trivial copy-assignment".
All the cases I checked were harmless; as long as a class has no vptr
or owns memory (or other resources) that need to be handled properly
in the destructor, memcpy() and memset() aren't too dangerous.
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.
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.
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).
(This includes "Fix ID_MAYBE_INLINE on non-Windows platforms")
Commented out the no_stamina bit. Stamina in Rivensin is used for the energy shield and not running. If this was set in a map, the shield was disabled. Noticeable if playing some user made maps and Hell levels in vanilla campaign.
For some reason the idMoveableArrow's animator didn't have a modelDef,
which caused masterAnimator->GetJointTransform() to return immediately
without setting masterAxis or masterOrigin - so they contained garbage
data which lead to NaNs which lead to trouble.
I check for that issue now to make sure they're initialized, but I'm not
100% sure this is a proper fix - the underlying issue is that this
animator has no modelDef. Is that bad? Could it create other issues?
No idea.
Somehow I must have added that
savefile->WriteFloat( spreadCrouchFactor );
twice when merging the Ruiner/Rivensin changes into the SDK.. damn.
(As it's only read once, all data read from the savegame after it
will be garbage)
I had a crash when creating a Savegame in idAnimState::Save(),
because animator was NULL - so I added a check for that.
The rest has been found with GCC address sanitizer (ASan)
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)
I hope I guessed this right: This could prevent the rare assertion
in RenderWorld.cpp:954 ("bounds[0][0] <= bounds[1][0]
&& bounds[0][1] <= bounds[1][1] && bounds[0][2] <= bounds[1][2]").
Cursor now uses 2 different guis based upon aspect ratio just like
the hud. This is due to the translations of of the cross hairs being
off if a 4:3 cursor is on top of a 16:9 render view.
Requires additional key in the player def just like the hud does.
In game menu no longer stretches. Looks much better.
This is the menu that displays the advanced controls.
(DG: based on revility's commit with same message, removed stuff already
implemented here and cleaned up the rest a bit)
pm_crouchviewheight updated. origin was set from near the player's stomach and not the neck
pm_thirdpersonsidescale default value reduced. Player can still adjust the amount in the main menu.
Added new cvar pm_crossHairSideScale
Corrected description of pm_ProjectileOrigin.... this does not effect projectiles. Only the tracers, models or particles attached to them.
adds a new cvar pm_crossHairSideScale to move the view position origin sideways. Useful if pm_crosshairorigin is set to 0 and aiming around corners. weapon projectiles use this as their spawn position. cross hairs use it as the origin of the trace line. default is 0. player should adjust to their liking and current camera settings. If set too far over, the player can shoot around walls.
removed bobbing and jittering while the crosshair origin is set to use a joint on the player model (pm_crosshairorigin 1). Was very noticeable while looking at steps.
Needed if you want to play some of the vanilla doom 3 maps by default. Note that you will need to update more stuff like statements, globals, etc. for the game to start with all of them. Another note that the scripts are not loaded by default in ruiner/Rivensin due to none of the maps being tested. Most of them are not third person friendly. Someday I hope to get a mini version of the campaign ported.
