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.
More or less.
This is a bit of an experiment (which seems to work nicely) in that qfcc
and pak are build natively in one build tree, then the full system is
cross-built in another tree using the natively build qfcc and pak. Both
trees are created by cross-configure.sh as sub-directories of the current
directory. However, cross-configure.sh still assumes it is being run in a
subdirectory of the main quakeforge directory.
cross-make.sh checks if the native tree is in the current directory and if
so, builds it, otherwise it just runs make for the cross-build tree (this
allows for running cross-make in a sub-directory for things like sorting
out build issues).
CC_FOR_BUILD is the recommended name these days (HOST_CC was from an old
gcc version, and is confusing anyway). Also, CC_FOR_BUILD should be set by
configure.
This should make maintaining them a little easier.
The copyright block in most of the new headers (execpt vector.h) reflect
when the functions in the relevant header were first created.
Unfortunately, just because the header is there doesn't mean anything will
actually work :(. Also, the check is based on the host vendor/os for now.
Yes, it's rather lame but it will do for now.
With this, QF will build on an almost fresh ps3toolchain install. Only two
"fixes" are needed:
o In $PS3DEV/ppu/powerpc64-ps3-elf: ln -s ../include sys-include
o libsamplerate cross-built and installed.
One common use for a mesh having multiple UV maps is when combining several
mesh objects into one: the base UV map is the result of joining the meshes
(and will be a right mess of overlapping UV islands), but an additional UV
map is then setup as a copy of the first but with the islands re-packed so
nothing overlaps. The export script now searches for the active UV map and
uses that for both UV coordinates and the skin texture (when none is
specified).
If there's no export script, or the export script has no frame information,
animation data will be collected by running through blender frames 1 to the
current frame (inclusive). Each frame will be exported as a single frame
rather than as members of a frame group.
