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
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)
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.
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.
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.
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.
Sometimes memory was allocated with new[] but freed with delete instead
of delete[], which is wrong.
And there were some small memory leaks, too.
Furtunately clang's AddressSanitizer detected all that so I could easily
fix it.
(There seem to be some more small memory leaks which are harder to fix,
though)
The assertion in idBounds::operator-(const idBounds&) was triggered
from idWeapon::Event_LaunchProjectiles() (ownerBounds - projBounds)
It only happened when using the BFG.
So I added a check to make sure calling operator- is legal.
I guess this also caused #122
While I couldn't reproduce the crash, according to the bugreport it
happens if renderSystem->GetScreenWidth()/Height() returned 0 - and
that is indeed the only plausible reason I can imagine for it.
So I check for that case and handle it gracefully by defaulting to
4:3 FOV values.
idAnimator::GetJointLocalTransform() miscompiles with gcc 4.5 and
-ftree-vrp (implied by -O2).
Reorder code to avoid the compiler bug, no functional change.
The original commit was for game/ only, but d3xp/ will have the same
issues..
Added r_aspectratio -1 which means "auto" (as new default).
This mode sets fov_x and fov_y according to screen-width/height.
=> No need to set r_aspectratio manually anymore (assuming your display's
pixels are about square).
The standard aspect ratios can still be enforced as before, though.
This was only implemented with MSVC style asm.
Comments suggest that it was used to help catch invalid FOV calculations,
which were probably only happening with ancient compiler bugs.
(Except for handling of longs in TypeInfo and win32-only Maya import stuff).
sizeof(long) == sizeof(int) on x86 and win64,
but not on 64bit (x86_64) linux/unix/osx/.. so they should be avoided.
Monsters got stuck in same places of d3xp because PVS calculations
returned that they were not in the players PVS.
This only happened on LP64 systems like Unix/Linux amd64 where
sizeof(long) == 8 - it did not happen on Win64 because it's LLP64, i.e.
sizeof(long) == 4 (like on x86 32bit).
Bit fiddling code in Pvs.cpp seemed to assume that sizeof(long) == 4
like on win32.
Fixes#7.
Fix silly issue from 3d692b58 (sizeof(E_EVENT_SIZEOF_VEC)).
Align entity values of events to the native pointer size, which
is noticeably faster on x86_64 and fixes another assert() in
debug builds.
Past savegames with entities in events are not compatible.
The argument size of each event is checked in debug builds
and this change was missing from the x86_64 commits.
Surprisingly this didn't trigger yet with the original game,
only with the mod 'Classic Doom 3'.
Required for events with string arguments. On debug builds
an assert() is triggered when trying to save such an event,
while events could not be properly restored in any build.
This happens when going from map delta4 to hell1 and the
autosave feature kicks in. The trigger event 'selectWeapon'
with the string argument 'weapon_fists' is in the event queue.
With the binary from id a warning is issued:
WARNING: player1 is not carrying weapon ''
so the bug exists in there too, just that its a release build
and doesn't abort().
I also managed to trigger this while saving shortly after
activating an elevator switch.
