Cosa è cambiato in EDuke32, build per build

Risolve

terminx/eduke32#83

A value of -1 now indicates that the GL state should be preserved. This is used to fix terminx/eduke32#159

Annulla

33d4dc3 — Duke3d: MASTERSWITCH counting down before activation blocks re-triggering switches (Build 9391)

Risolve

terminx/eduke32#150

Risolve

terminx/eduke32#152

This is better for clarity, I think.

This should fix terminx/eduke32#16

Risolve

terminx/eduke32#153

Debug is now configured to use AddressSanitizer on 64-bit, and various other build options have been made uniform with each other across all projects. This means 64-bit debug builds built with Visual Studio will only run if the VS ASan dlls are in your PATH, but I believe this is fine as we don't distribute any VS builds.

I didn't test this.

You're gonna have to talk to me or read the source for full details on usage, sorry. These are also all still liable to change in future builds, either in name or in functionality.

The default value is 256 (GRAVITATIONALCONSTANT value from USER.CON + 80).

This is still technically a work in progress, but it's at the point where it's definitely better than things were before.

A helpful side-effect of this commit is that several of the previous changes to how screen re-centering etc work can now be deterministic again, which somewhat fixes demo recording and playback. For now, recording a demo will limit input to the game tickrate like it did in the old days.

It's beyond useless at this point and nobody ever even ported the assembly to C. I left the actual kensmessage string because I didn't want to remove a copyright declaration from the source code.

This is possibly a good candidate for outright deletion.

Disassembly of the tweaked version versus the original is very similar, but MSVC doesn't seem to want to inline the original version without forcing it. I tested the performance of the change under GCC using a very large loop and the results were in favor of the tweaked version by a negligible margin. FORCE_INLINE was added after the fact.

This shouldn't have any impact whatsoever on gameplay. The point was simply to eliminate branches that arrive at the same result, and reduce function calls for cases where they aren't needed (i.e. calling A_CheckEnemySprite() for sprites that are STAT_PROJECTILE).

This didn't really affect anything because this functionality isn't exposed to CON yet.

This is a hack intended to fix an issue introduced back in SVN r7409, where the reduced speed of a projectile during its first tic (required for fixing the issues with projectiles passing through ledges immediately in front of the player) could inadvertently allow the player to do stuff like SR50 into their own RPGs.

The way this code works is pretty weird. It seems like the movement hiccup here was caused by intentionally skippping the state of the camera where pData[1] == 0, but I can't find anything else in the code that depends on the value of this field for CAMERA1, and fixing the hiccup causes no issues in any of the setups with panning cameras that I looked at for testing.