This ensures that we call ARM64 `aarch64` on all platform, which aren't
MacOS or Windows. And it fixes the bug, that `arm64` was normalized to
`arm`, making incompatible savegames between 32 bit and 64 bit ARM
loadable. Leading to crashes.
.. and use YQ2ARCH and YQ2OSTYPE instead of just ARCH and OSTYPE
for the defines, so it's consistent with the engine and xatrix+rogue.
$PROCESSOR_ARCHITECTURE seems to contain the architecture of the host,
but we need the architecture the current MinGW shell is targeting.
$MINGW_CHOST seems to be just that, and on my system it's either
i686-w64-mingw32 (mingw32.exe) or x86_64-w64-mingw32 (mingw64.exe)
(No idea what it looks like for Windows on ARM...)
As fixing this would otherwise break existing savegames, I bumped the
SAVEGAMEVER to "YQ2-4" and added a quirk for older savegameversions:
On Windows i386 savegames that contain "AMD64" instead of "i386" as
architecture are also accepted.
(For YQ2-1 this didn't seem necessary, apparently "i386" was hardcoded)
- Switch from an whitelist base approach regarding platforms and systems
to an blacklist approach. This is savegame version 2.
- Fix coop_respan struct not fully initialized after savegame load while
running in coop mode. This is savegame version 3.
Support for savegame version 2 was added to keep the divergence between
zaero and the other addons low.
I added more missing fields to savegame/tables/fields.h and reordered
everything to make missing fields easier to find.
This broke savegame compatibility, and that might happen again.
I hope I'll remember to bump the savegame version before merging this
branch to master.
I also got segfaults (e.g. when a door was blocked by a corpse) in
G_UseTargets() because activator was NULL.
And in g_cmds.c there was a typo in OnSameTeam() - from the relatively
recent fix. No idea why, it doesn't exist in the other addons..
See https://github.com/yquake2/yquake2/issues/71
and https://github.com/yquake2/xatrix/issues/4
In ClientThink(), the float value ent->velocity[i]*8 is saved into
a short and if the value is too big for a short, in 32bit gcc builds
the short is set to SHRT_MIN, resulting in the player being pressed
down instead of up.
Now we put the result in a 32bit int first (which should be big enough)
and assign the int to the short. This still overflows, but with -fwrapv
at least in a defined way (most probably the same way the original
binaries did).
The Makefile now sets $CC to gcc for MingW builds, this should fix
https://github.com/yquake2/xatrix/issues/3
And while I was at it, when the game lib is loaded, it prints the date
it was built, this is especially interesting for our Win32 binaries.