There's still some cleanup to do, but everything seems to be working
nicely: `make -j` works, `make distcheck` passes. There is probably
plenty of bitrot in the package directories (RPM, debian), though.
The vc project files have been removed since those versions are way out
of date and quakeforge is pretty much dependent on gcc now anyway.
Most of the old Makefile.am files are now Makemodule.am. This should
allow for new Makefile.am files that allow local building (to be added
on an as-needed bases). The current remaining Makefile.am files are for
standalone sub-projects.a
The installable bins are currently built in the top-level build
directory. This may change if the clutter gets to be too much.
While this does make a noticeable difference in build times, the main
reason for the switch was to take care of the growing dependency issues:
now it's possible to build tools for code generation (eg, using qfcc and
ruamoko programs for code-gen).
They take a pointer to a free-list used for hashlinks so the hashlink
pools can be per-thread. However, hash tables that are not updated are
always thread-safe, so this affects only updates. progs_t has been set
up such that it is easy for multiple progs within one thread can share
hashlinks.
After messing with SIMD stuff for a little, I think I now understand why
the industry went with xyzw instead of the mathematical wxyz. Anyway, this
will make for less pain in the future (assuming I got everything).
These are the ones where I could easily make scan-build happy. They do seem
to be potential holes where invalid data in one place could result in use
of uninitialized values.
While scan-build wasn't what I was looking for, it has proven useful
anyway: many of the sizeof errors were just noise, but a few were actual
bugs (allocating too much or too little memory).
This was caused by an out-by one error when setting up the skin: if cmap
was 0 then the gl_skin struct would be taken from index -1 of the array and
thus cause all sorts of grief.
GL sometimes crashes when building skins. This probably isn't the correct
fix (finding the situation where fb->tex can become NULL despite fb being
non-null is), but it does kill the segfault. Luckily, this is git and this
commit can just be reverted when the real fix shows up. :)
The search for these files will stop in the vpath that contains the .bsp
file to which they belong. This will prevent problems with
id1/maps/start.lit being used for shadows/maps/start.bsp.
Since the hull depth needs to be set for the hull to be useful, it makes
sense to move the code into the same place that allocates new hulls (to me,
anyway).
The depth limits in the gl and glsl renderers and in the trace code really
bothered me, but then the fix hit me: at load-time, recurse the trees
normally and record the depth in the appropriate place. The node stacks can
then be allocated as necessary (I chose to add a paranoia buffer of 2, but
I expect the maximum depth will rarely be used).
This fixes the horribly different results between optimized and unoptimized
qfbsp (there is still a difference of 1 brushface). Unfortunately, it also
severely limits the maximum size of a map.
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.
In the end, it turns out this is the correct fix for the gl seg on
overkill, because build_skin will correctly use the fully setup player skin
if the glskin doesn't have a texture associated with it.
Double converting texcoords results in 0,0 for all affected texcoords. Mr
Fixit was looking rather ill. Now he looks weird (something wrong in the
renderer?).
There are still many issues to sort out, but the basics are working.
Problems:
rendered fullbright (no lighting done)
normals are ignored
extra textures (glow etc) not used/loaded
4 models on the screen don't seem to be a problem.
