Rather than prefixing free_ to the supplied name, suffix _freelist to the
supplied name. The biggest advantage of this is it allows the free-list to
be a structure member. It also cleans up the name-space a little.
Sys_LongTime returns time in microseconds as a 64-bit int. Sys_DoubleTime
uses Sys_LongTime, converts to double and offsets 0 time by 4G (2**32).
This gives us consistent sub-microsecond precision for a very long time.
See http://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/
The ~ gets expanded to CSIDL_LOCAL_APPDATA, $HOME, $USERPROFILE or just
".", whichever succeeds first. The usual location will be:
"C:\windows\profiles\<user>\Local Settings\Application Data".
"." is now the fallback for *nix systems too.
This gives QF a consistent qualilty PRNG on all platforms. The
implementation is slightly different from the standard, but gives the same
results for the same speed (details in mersenne.c).
It seems the code expected octal escapes to always start with 0. This is
not the case. Also, octal escapes are limited to 3 digits (and hex to 2).
This fixes the garbled bold text in ITS.
The bsp2 header is not necessarily correct (or even present), but the bsp29
header is: it was setup via set_bsp32_write. This fixes the bsp corruption
when vising a map (and, I expect, any problems with qfbsp on a big-endian
machine).
qfcc now does local common subexpression elimination. It seems to work, but
is optional (default off): use -O to enable. Also, uninitialized variable
detection is finally back :)
The progs engine now has very basic valgrind-like functionality for
checking pointer accesses. Enable with pr_boundscheck 2
Getting everything right with an enum proved to be too difficult if not
impossible. Also use better tests for equivalence and intersection.
Many more tests have been added. All pass :)
Also move the ALLOC/FREE macros from qfcc.h to QF/alloc.h (needed to for
set.c).
Both modules are more generally useful than just for qfcc (eg, set
builtins for ruamoko).
While accessing short foo[2][4]; as foo[0][0..7] should work in theory, who
knows what gcc does with it when optimizing. I don't know if this will fix
johnnyonflame's bsp loading problem, but no point in having rhinodemonic
code hanging around.
This necessitated disabling the id2 padding, but it's only commented out
incase there's more growth. Now the (compiler) error in -addObjectNoRetain
is caught ealier.
Need to subtract the size of the bsp_t/bsp29_t struct. Now old and new
qfbsp produce identical bsps (so long as they're both unoptimized, or
(probably) both optimized).
All of the nastiness is hidden in bspfile.c (including the old bsp29
specific data types). However, the conversions between bsp29 and bsp2 are
implemented but not yet hooked up properly. This commit just gets the data
structures in place and the obvious changes necessary to the rest of the
engine to get it to compile, plus a few obvious "make it work" changes.
I didn't like the way client/server code was poking around at the
implementation. Instead, provide a couple of accessor functions for the
same information.
And the tests really exercised VectorShear (first attempt had things
messed up when more than one shear value was non-zero). Also,
Mat4Decompose wasn't orthogonalizing the z axis row. Oops. Anyway,
Mat4Decompose is now known to work well, and the usage of its output is
understood :)
It seems (some versions of) windows vsnprintf don't count the terminating 0
when limiting the number of chars written to the buffer. Nor do they
guarantee the output string will be terminated.
I got the idea from blender when I discovered by accident that quat * vect
produces the same result as quat * qvect * quat* and looked up the code to
check what was going on. While matrix/vector multiplication still beats the
pants off quaternion/vector multiplication, QuatMultVec is a slight
optimization over quat * qvect * quat* (17+,24* vs 24+,32*, plus no need to
to generate quat*).
One's an actual bug, the other a bit of error checking (not sure how
necessary it is, but it's in code that we don't /want/ to run, so it can't
hurt :)
Thanks to spirit for pointing that QF wasn't compiling with zlib 1.2.6
(archlinux, not yet in debian).
I was using gzFile as "gzFile *gzfile", but gzFile is already a pointer. In
older versions of zlib (including the 1.2.3 that's in debian), gzFile is
declared as a void *, and it seems that gcc is happy with assigning void **
to void *. However, in recent zlib, gzFile is now struct gzFile_s *, which
gcc is most definitely unhappy about assigning to struct gzFile **.
I just hope that either I had misread the type back when I wrote quakeio,
or that nobody is using such an ancient zlib.
o All instances of LIBADD/LDADD have a corresponding DEPENDENCIES
specificatiion.
o libraries now use a lib_ldflags macro to keep things consistent
o duplication of source/lib names has been minimized (particularly in
the libraries; more work needs to be done for the executables)
o automake spec blocks have been organized (again, more work needs to be
done for the executables)
Buffer underflow and though strcpy has always been safe there, change to
memmove. Had the added benefit of helping me create more test cases for
better coverage.
Yay, Deek for finding another bug in qf :). He had an old dirconf that
didn't specify HudType and thus caused the status bar code to blow up. Set
the default to "id" if none is found.
I got rather tired of there being multiple definitions of mostly compatible
plane types (and I need a common type anyway). dplane_t still exists for
now because I want to be careful when messing with the actual bsp format.
