On each invocation of CL_SetSolidEntities, the previous state gets
overwritten, so only the last call matters. So it should be safe to
lift out from CL_ParseServerMessage, then out of the loop in
CL_ReadPackets and finally up into Host_Frame in cl_main.c.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Now cl_cam.c does not refer to the global pmove, and Cam_Track is the
single point of entry. Now to see what other dependencies might be
hiding around the palce - maybe it can be localised further...
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
All the Quakeworld client pmove trace functions seem to be pretty much
identical to the server ones originally from world.c, so shared all
the bits which are common and remove that duplicated code.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
This neatly cleans up a makefile hack since now all targets use the
ASM implementation of Mod_HullPointContents. Removes a bunch of
duplicated code and also make Pmove_Init unneccessary.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Try to avoid cases where -180 != 180 or 0 != 360 by ensuring that we
use the ranges (closed->open) of [0, 360) or [-180, 180).
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Nothing really to change except the headers included and the library to
link against. Switched on WIN32_LEAN_AND_MEAN, so had to add a few extra
includes for that.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Lost my mind for a while there - snprintf always terminates the
buffer. A couple of minor tidy ups in nearby code while I was looking
over all the calls.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Rather than needing external checks on the output buffer, or adding a
"max length" parameter and needing to check for overflow, etc., make
COM_StripExtension modify the existing string.
Callers updated as needed.
A personal note that I finally realised that snprintf always zero
terminates the output buffer! So that should tidy up existing code a
little more and makes it an even better replacement for strncpy in
almost every case.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Generally try to consistently handle buffers where MSG_ReadString is
concerned. Scary the number of places where buffer sizes are
incorrectly handled.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Reduces a bit of the extra buffer copying and reliance on va(). Buffer
length checks for a few cases now consolidated into one place.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
SZ_Print is really meant for occasions where we need to build up a
string via strcat into the sizebuf - MSG_WriteString is more
appropriate in the cases fixed here, usually following a
MSG_WriteByte() anyway, so nothing to append to. Use the
MSG_WriteStringf variant where appropriate to reduce reliance on the
va() buffers.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Presumably a simple anti-cheat precaution to stop people running "strings"
on the binaries in the days before the source was available. The
de-obfuscated strings are sent over the wire in the net protocol anyway.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
