Turns out there are two types of "BSP2" format - one that I think was
created by MH and implemented in the RMQ project (this is the one I
implemented previously) and one by LordHavoc which exteneded the
coordinate limits beyond 32k, implemented in Darkplaces. The
Darkplaces version of BSP2 will get the name BSP2 and the RMQ version,
which is more limited, will get the name BSP2rmq.
qbsp will only create the BSP29 or BSP2 formats, but will cope with a
BSP2rmq format file for an -onlyents compile. The rest of the tools
can use any of the three formats.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Won't produce a working bsp2 file yet, but if you ask for bsp2 on the
command line now, faces and edges will be output in bsp2 format.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Kind of taking a step backwards here to where we were, but make the
MemSizes array dynamically changable so that we can switch out and
allocate BSP2 sized elements when we want to write a file in that format.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Some of the bsp2 data structures are bigger than the bsp29 structures, so
we need to know the difference in allocation size. Stop using the data
structure enum for lump numbers.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Also do a quick sweep of the source and consistently use %d instead of
%i (no real difference, but just pick one).
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Instead of doing awkward gymnastics to try and load the brushes and faces
into memory in reverse order for compatibility with the original qbsp,
just load them in map file order.
Simplifies iteration over the data, particularly if I want to load less
items than the pre-parse found.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Future work will break the assumption that the number of used items will
be equal to the maximum number of items, so separate the two numbers.
Replace use of maxblah with numblah as appropriate.
This makes the reverse order loading or brushes, etc. look even more
painful, so will look at whether we can change that now. As far as I know
no editors do clever things that would make the map compile "better" in a
different order - it's just that it might break some previously working
maps if they were an edge case that different ordering makes the precision
flip in a non-favourable direction.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
It does make them somewhat less greppable, but makes the variable naming
style more consistent with the rest of the quake utilities.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
The count members are actually where we store how much memory has been
allocated for each type of item in the mapdata struct, so rename these to
indicate these are the maximum counts.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Remove the big union in mapentity_t, collecting together the information for
each lump in a struct. Still not 100% sure where I'm going with this, but I
think this will help me with removing some of the reliance on globals further
along (which will be important once it comes to multi-threading).
Signed-off-by: Tyrann <tyrann@disenchant.net>
Now that we're compiling as C code, the memory returned by AllocMem no longer
needs to be explicitly cast when assigning to our typed pointers.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Replace the "File" class with basic stdio C functions. The LoadFile is kept
basically intact. All instances of File objects are replaced with FILE*. Calls
to member functions are replaced with inline C code. There is some redundancy
with the error checking, but this can probably be cleaned up a little bit by
using some of the SafeOpen, etc. functions from common/cmdlib.c.
Signed-off-by: Tyrann <tyrann@disenchant.net>
More source mangling; run indent over the source files to make it more
consistent with the rest of my utils code. Remove any trailing whitespace
while we're at it.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Import QBSP sources from Greg Lewis' TreeQBSP version 1.62.
- http://www.yossman.net/~tree/
Thanks to Greg for allowing me to use his modified source code:
On Fri, Aug 25, 2006 at 04:28:24PM -0400, Tree wrote:
> I imagine you've already gone ahead with your plans, but feel free to do
> whatever you wish with the source for TreeQBSP; I have no interest in
> restricting anyone's access to it (and of course I was just modifying id's
> code anyway). I'm just glad to see that it was of some use to you. :)
>
> Greg
The files are unmodified from the originals, apart from lower-casing the
filenames and removing ASCII CR characters from end of lines.
Signed-off-by: Tyrann <tyrann@disenchant.net>