GNU platforms (Linux, kFreeBSD, Hurd) have endian.h to determine
endianness, so all architectures except x86_64 are in fact treated
identically, except that their ARCH_STRING is different.
The ARCH_STRING must always be identical to the ARCH from the Makefile,
otherwise the engine will not find its cgame, game and ui plugins
under their expected names and startup will fail. If we pass it in
from the Makefile, then an identical value is guaranteed, and we can
get rid of an increasingly long list of defined(__some_cpu__) tests.
The one remaining quirk is that we test __x86_64__ to determine
whether to define idx64; I've kept that, but separated it from
the ARCH_STRING.
On non-Linux platforms we only support a few architectures anyway,
so keeping the list up to date is less of a burden; *BSD porters
could probably use the same technique to get support for lots of
architectures with little effort, but I have not done that here,
because I cannot test it.
Windows must continue to support preprocessor-based architecture tests
in any case, so that the MSVC solutions (which do not use the Makefile)
can continue to work. However, Windows only runs on a few CPU families,
so this shouldn't be a significant burden in practice.
When cross-compiling, the tools are compiled for the build architecture
(COMPILE_PLATFORM, COMPILE_ARCH) rather than the host architecture
(PLATFORM, ARCH), so define ARCH_STRING to COMPILE_ARCH on a GNU
COMPILE_PLATFORM.
MASK_REG in EmitMovEDXStack would incorrectly emit asm if 'andit' was 0.
'andit' would never be 0 though so it wasn't causing issues.
Found by Coverity.
Windows' Sys_ListFiles would add files that contain the extension anywhere,
not only at the end of the file name.
Example: "word.pk3omghacks" use to be loaded as a pk3 file.
My last commit made it so that CGame "waterlevel 1" is feet in water,
but before it was erroneously about waist deep in water. The places
where it is checked it is suppose to be view position underwater.
Change comparisons to use correct value for view position underwater.
CG_WaterLevel() added lerpOrigin to itself instead of adding view height
when checking for waterlevel 2 and 3. This did not cause issues because
ioq3 only compared the calculated waterlevel to more or equal to 1.
Cinematic's startTime and lastTime are always set from CL_ScaledMilliseconds
which returns int and are converted back and forth to int and unsigned int.
This fixes a warning that abs() is used on an unsigned int.
If a bot is accompanying someone before map change or restart, the bot would
continue accompanying them but press up against them and orbit around them.
This is caused by the bot's formation distance being 0.
Save the formation distance so they maintain proper distance and do not
orbit around the player.
When the engine is compiled with Clang it appears that the return value
is being written to the WRONG address, either due to the vm_ variables being
changed (unexpectedly) elsewhere, or as a result of bad assembly assumptions;
having a stack variable pointing to where to write the return value seems
to do the trick.
This fixes the case where, for a trap_Register()-like call, weird numbers
are being returned when, during the process, an error message is printed
(which in Tremulous results in a QVM call and (nested) system call).
The renderer color is set to health color when drawing crosshair. After
drawing the crosshair, the renderer color was not cleared and could affect
other things. With cg_draw3dicons 0 and cg_drawCrosshairNames 0 it affected
the attacker icon.
Hopefully fixes the following warning
cg_draw.c:2315 assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow]
