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>
Add BSP2 support to the remaining utils. Since these share the common
bspfile.[ch] files, it was more effort than is justifiable to break this
into multiple staged patches - so you just get this disgustingly big
commit instead. Here is basically what was done:
* Modify the bspdata_t struct with a union of the two bsp formats
* Modify the tools to use bsp2_t for all internal processing
* Split out the byte swapping routines for the different bsp data types
* Add simple (although verbose) code to convert bsp29 <-> bsp2
Hundreds of lines added to bspfile.c, but mostly trivial stuff. The tools
internally had little modification except to substitute the bsp2 type
names.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Transition all tools to access the BSP data via the bspdata struct instead
of the shared globals. Remove the compatibility code from bspfile which
copied the global values to/from the instanced bspdata struct.
Mostly the changes just involved passing along the bspdata struct to the
various functions which needed to reference the data. TraceLine and
MakeTNodes in light got some extra changes so that we cache the node
dplane pointer and remove the need to pass the bspdata struct to every
trace operation!
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Avoids reference to global LightDataSize. Need to move writing the lit
file above the call to WriteBSPFile, since that will do the byte swapping.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Rename the default bsp29 data types and add the bsp2 data types to
the common bspfile.h. Propogate the bsp29 names into the other tools as
simple renames for now.
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>
In preparation for bsp2 support, add the data types for bsp2 structures
to bspfile.h and rename the bsp29 structures to properly differentiate them.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Used this to help with debugging, but may as well keep it around for
future debugging rather than implement it all over again next time.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Unable to represent this in the bsp29 format, so let the user know instead
of silently corrupting the bsp.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
We take care of adding extra animation frames during loading of the map
file to ensure that we add lower-numbered texture frames before the higher
numbered frames. Most Quake engines will choke on a BSP if the texture
frames are presented out of order (including the original).
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Provides a modest speedup on Windows, where this operation is ridiculously
slow. Not a huge number of files on this project, but the speedup is
measurable.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Often these errors are caused by super small faces on brushes, show the
area of the offending face to make it more obvious if that is the case.
Kind of lost in the diff, but moved the TriArea, etc. functions up and
added FaceArea() and then augmented the error message.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Rather than allocating the overflow map within each function and
having to handle it as a special case in each, we always allocate the
extra lightmap in the base LightFace function and use common helper
functions to handle allocation and warning on overflow.
We lose a tiny bit of debugging info here about the specific light
that made the surface overflow MAXLIGHTSTYLES, but that never gave us
all the sources, only the last one encountered.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Simple functions, but just helps to tidy up the bodies of the other
LightFace functions and makes sure we're handling light & colours
consistently across each (we weren't in the case of coloured local
minlights, previously).
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Move away from the "Fix" naming ~ it's not a fix, we're applying the
minimum lighting values as requested.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Factor out the allocation of new light styles - slightly increases the
code size, but we get two benefits; first is that we now don't
allocate the style 0 lightmap unless we actually need it; second, we
get warnings if sunlight or minlight is unable to be applied due to
lack of a style 0 lightmap.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Kevin Shanahan