Need to be a little more careful to order brushes correctly when adding
detail to the worldspawn. CSGFaces assumes that the brushes are ordered
such that earlier brushes have chunks carved out of them by any later
brushes that intersect them.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
During conversion from map brushes to bsp brushes, set the brush detail
flag for later use in CSGFaces().
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Pull the progress output up into the caller (not ideal) to deal with the
fact we are making extra calls to load the detail entities for the
worldspawn.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
The first step towards supporting detail brushes for Quake 1. This gives
us a way to add detail brushes to a map within the existing mapping tools. A
mapper can simply add a definition for a "func_detail" entity to their
editor and create func_detail entities.
Of course, currently they will behave exactly like world brushes. Future
patches will start to treat them differently.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Make Brush_LoadEntity() take a source and destination entity arguments. In
order for this to work, intialisation is done before calling and then the
BSP brushes generated from the source entity's map brushes are added to
whatever is already in the destination entity.
Reasons for doing this will become obvious with the following patch! :)
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Less error prone as it's usually followed by a strn?cmp or something.
Callers that were relying on null checks updated.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Still have the limitations of MAX_FACES, etc. but in practice it's
probably not going to be an issue.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
We don't need very precise time - only used for telling the user how long
the compile took, so use the most portable API. Fixes compilation on
OpenBSD/FreeBSD.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
The previous code would possibly leak faces with weird effects if we
iterate over the face data e.g. 0 -> map.numfaces.
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>
Not enabled, but may as well keep it up to date in case we want to start
using it. Might be useful as a simple check that we aren't leaking memory
somewhere.
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>
* ParseEntity/ParseBrush now take a mapface_t argument, endface
* mapbrush_t now defines a pointer to first face and count of faces
* entity->iFaces no longer needed
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Tidy up the functions that calculate the texinfo data for either QuakeEd
or QuArK texture coordinates.
* Remove cleverness in SetTexinfo_QuArK where checking style1 or style2
just expand the loop for both cases for increased clarity.
* Pass the face plane into SetTexinfo_QuakeEd so it doesn't need to rely
on map.iFaces.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Instead of iBrushStart and iBrushEnd, we now store a pointer into the
mapbrush array and store the count of brushes for this entity. pBrushes
and cBrushes members are renamed to brushes and numbrushes, respectively.
The iBrushes member of mapentity_t is no longer needed.
At this stage we still go through hoops to load the brushes in reverse.
The original comment indicates that this was needed for compatibility, I
may try simplifying and loading in map file order and see if that has any
ill effects on compilation of test maps.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Make the caller look up the fixed origin again if they need it rather than
always passing in/out an origin. FindTargetEntity also now returns a
pointer rather than entity number.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
* Pass in pointer to the entity and mapbrush instead of brush number
* Rename some local variables for better readability
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Stop RecursiveFillOutside from blowing up the stack by making sure it
doesn't pull in MarkLeakTrail when GCC optimiser starts inlining stuff.
Might be an idea to make a non-recursive version of FillOutside at some
point, since it can go *very* deep on complex maps.
Signed-off-by: Kevin Shanahan <kmshanah@disenchant.net>
Set up a sphere around each face so we can do quick tests against planes to
see if there's any chance that it intersects the face. Since we're only using
it for a fast check, don't bother shrinking the sphere when a face gets cut or
split, just grow it when necessary (only in TryMerge AFIACT).
Signed-off-by: Tyrann <tyrann@disenchant.net>
The choice of the various epsilon values is critical to having geometrically
complex maps compile correctly.
The one which seems most important (so far) is the ANGLE_EPSILON. This one
needs to be quite tight to avoid "bad things" happening when you create small
angles between adjacent surfaces.
Another epsilon inter-relationship I discovered, is that it seems
CONTINUOUS_EPSILON needs to be larger than EQUAL_EPSILON. It seems to play
havoc with the t-junction code otherwise.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Offsets pointing to clipnodes were originally used as signed short (16-bit)
numbers, so that negative numbers could represent the various content types of
leaf nodes. However, only a small number of these types are required, so we
now make use of the rest of the clipnode range.
Signed-off-by: Tyrann <tyrann@disenchant.net>
When writing out portals for a node, we can skip over portals that separate
volumes with the same contents. The existing logic I find very hard to follow,
so I've separated that out in an attempt to make it more understandable.
While we're at it, equivalent logic is required in NumberLeafs, so re-use.
Signed-off-by: Tyrann <tyrann@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>
Ugh, looks like this extraneous line snuck in with commit 6bb3ad32
While I'm here, I see no reason to zero pWorldEnt->cTexdata just above
either. It should already be zero'd memory from the malloc of map.rgEntities.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Fix the logic that decided which edges were to be added to smooth the clipping
hulls. The original logic is completely backwards and throws away all the hull
edge clipping planes you want, while potentially keeping the worst corner
cases.
This patch corrects that logic - for that reason, regressions are expected as
we will now be adding more planes to the maps and clipping more things at
wierd angles. Compile times will probably increase and clipping errors will be
more common, at least until some more tuning of the various epsilons is done.
While we're hacking the function, hoist some calculations from the inner loops
up to the outermost loop. Not that this function is that performance critical.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Small cleanup to TestAddPlane - re-use the PlaneEqual and PlaneInvEqual
functions and replace the "counts" array with simple booleans to record which
side of the plane has points.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Use a hash to speed up FindPlane for maps that have huge numbers of
planes. Not many maps have enough planes that this is a win, but those maps
are the ones where speed matters most. :)
Signed-off-by: Tyrann <tyrann@disenchant.net>
Instead of just assuming that 9999 or similar is "big enough", use the
implementation defined type limits.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Make ChooseMidPlaneFromList a bit more picky about the non-axial planes it
selects. This can matter a lot for maps which have a lot of non-axial-aligned
brushwork (e.g. terrain, etc.) The number of clipnodes can skyrocket if planes
are not chosen with at least a small amount of care.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Factor out the common split plane metric code from the SelectPlane*
functions. While we're at it, make it also work for non-axial planes using the
DivideBounds function.
Signed-off-by: Tyrann <tyrann@disenchant.net>
To make testing easier, log the output of the job to mapname.log, rather than
qbsp.log. Probably more desirable to make the logfile selectable in the long
term, but this will help for now. Note that we now don't open the log file
until after parsing the command line options, so the Message function needs to
check the file handle before writing to it.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Add the "-wadpath" command-line argument to allow the user to specify a
directory where wad files can be found. If no wadpath is given, the path
defaults to the directory where the map file is located. Absolute path names
in the worldspawn "wad" key should also work.
Signed-off-by: Tyrann <tyrann@disenchant.net>
If we run out of memory, then too bad. Qbsp never _really_ takes so long that
you'd really care too much about starting again. Simplifies portability.
Signed-off-by: Tyrann <tyrann@disenchant.net>
The options are currently parsed as a big text array, so that the parsing
function can be shared with the code to load options from a file. Anyway,
dynamically allocate the array to copy in the command line arguments rather
than restricting it to 512 bytes.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Fix numerous places where epsilons have been hard-coded, substituting one of
the defines from qbsp.h.
A couple of epsilons have actually been changed in this patch; the one used to
detect degenerate QuArK texture coordinates has been loosened (so the test is
actually a little more strict). The other is the test for flipped portals. If
my understanding is correct, then result would actually be < 0 if the portal
winding normal flipped, so this change _should_ be harmless.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Save some memory in CSGFaces by not splitting faces outside the brush being
processed. Normally these faces will be split by the planes of the brush, even
if the brush doesn't intersect with it at all. This also saves some time in
MergeFaces, since we don't need to re-assemble these faces again.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Each of ClipWinding, DivideWinding and SplitFace need to calculate on which
side of the split plane each winding point lies. Split this operation out into
a shared function.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Rather than using it's own type of winding, make face_t use the existing
winding_t struct to define it's edges. I tried dynamically allocating the
winding as needed, but it was a net performance loss (though much better for
memory usage). For now we'll just embed a winding_t struct inside face_t
instead.
Signed-off-by: Tyrann <tyrann@disenchant.net>
The number reported for peak memory usage by winding_t structs was not
accurate, due to just using the sizeof(winding_t) for accounting. Track the
_bytes_ used by each type in a separate array. This is pretty much redundant
for everything except windings, but it's the simplest way to implement it for
now.
Also tidied up the verbose memory output a bit - the total column is pretty
useless, so just don't print it. Re-align the other columns and special case
the "Total" line, as only the "Peak Bytes" value is really interesting.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Make all WADList functions take a pointer to the first wad_t, rather than
embedding it inside the struct wadlist. wadlist_t is no longer needed.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Begin breaking down the wadlist_t structure by having the Init function return
the number of wads loaded to the caller, rather than relying on just setting
it internally.
Signed-off-by: Tyrann <tyrann@disenchant.net>
If the map has no wad key, or none of the wad files found in the key can be
loaded, then try loading mapname.wad as a default.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Add back the warning message about invalid wads. Don't bother to differentiate
between filesystem errors and bad magic, etc. The file is already open, so if
we can't read it's either too small or there might be some hardware problem
(not worth dealing with separately).
Signed-off-by: Tyrann <tyrann@disenchant.net>
Move the logic from WADList_LoadLumpInfo into WADList_Init. Now the init
function will open all the wad files, testing for validity. Note that I still
need to tidy up the error handling and warnings a little bit to handle the
difference between filesystem/read errors and invalid/corrupt wad files.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Renaming a few variables to keep things nice and clear:
- w -> list ; the wadlist_t
- list -> wadstring ; the string from the map's "wad" key
- wad -> w ; local pointer to a single wad
Signed-off-by: Tyrann <tyrann@disenchant.net>
Rename a couple more structure members to make their purposes clearer;
- wad_t::Wad -> wad_t::file - it's a file handle
- wadlist_t::wadlist -> wadlist_t::wads - yes, we already know it's a list
Also, get rid of fileT from WADList_LoadLumpInfo.
Signed-off-by: Tyrann <tyrann@disenchant.net>
The wad_t struct is actually a list of wads, and the wadlist_t struct
represents the info for a single wad. This is kind of backwards, so reverse
the names. A few function renames went along with this to make things look
saner.
Signed-off-by: Tyrann <tyrann@disenchant.net>
wad_t::name isn't required outside of some temporary usage in WAD_InitWadList
so doesn't really belong in the struct.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Memory stats are reported inaccurately because the memory allocated to
windings is not accounted correctly (when freed, in particular). Use the usual
technique of recording the allocated size in the same block of memory, just
before the portion returned to the caller.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Fix a bug introduced in my class File -> stdio conversion. Don't use the len
variable to save the result of fread, since it's still needed as part of the
loop condition!
Signed-off-by: Tyrann <tyrann@disenchant.net>
QuArK generates floating point values for the brush face plane points and also
has it's own way of defining texture placement. Read in all plane points as
floats (does no harm maps that use integers) and also parse the extra comment
at end of line which indicates that the special texturing rules apply to the
face (two variants).
Signed-off-by: Tyrann <tyrann@disenchant.net>
Move the QuakeEd style texture vector calculations out of the ParseBrush
function. This will keep things tidier when adding other the other types of
texture vector calculation.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Change the boolean argument to parsetoken to a set of optional flags. Calls
that previously had crossline == false now pass PARSE_SAMELINE instead. Add
PARSE_COMMENT flag to parse the next token as a comment. If the token isn't a
comment, then return false.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Specify const where applicable in the VectorXX functions. This fixes a
compiler warning introduced in the last patch.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Since we've already generated a bsp tree at this point, we may as well use our
knowledge about it's properties. If our line is completely on one side of the
decision node, we only need to recurse down one of the child nodes.
Signed-off-by: Tyrann <tyrann@disenchant.net>
We need to allow for floating-point imprecisions when testing a line against
collision with bsp surfaces. This fixes a problem where the simplified leak
line generated would appear to pass through solid surfaces in the bsp.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Set the vec_t type to "double" using the DOUBLEVEC_T preproccessor define. Fix
up hard-coded usages of float in various places throughout the code. Note that
texinfo_t is an on-disk structure, so that needs to stay as float and we work
around incompatibilities with the vector functions using a temporary vec3_t.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Make needlessly global functions/variables static.
Move some checking functions inside an #ifdef PARANOID section.
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>
Now that all the C++isms have been removed, rename the .cpp source files to .c
and remove the special case makefile rules for compiling qbsp object files.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Replace three "const" declarations in qbsp.h with #defines to prevent multiple
definitions being compiled in when compiling as C code.
Signed-off-by: Tyrann <tyrann@disenchant.net>
There's a couple of usages outside of the AllocMem/FreeMem functions. Flag
these as something to look at later.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Nothing too exciting here, just replacing more C++ code with plain C. The
parser class is gone - we just use a global token now and call ParseToken to
update it.
Signed-off-by: Tyrann <tyrann@disenchant.net>
Replace the WAD class with plain C code. Class WAD becomes wad_t and the
member functions are just normal functions taking a wad_t as an argument.
The iWad member was a bit strange. It was used in some member functions for
walking the wadlist array. I've elimanted that from the struct and made the
functions track that state themselves.
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>
Make some bare-minimum changes to get qbsp to build with gcc/g++ and
MinGW/Msys.
o Added makefile rules
o Work around windows specific calls to e.g. _getcwd
o Use noecho() / echo() calls around getch() in Linux
o Substitute stricmp -> strcasecmp (in Makefile for now)
o Fix non-portable (incorrect?) of inline
o Fix misuse of delete where delete [] is required...
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>
Kevin Shanahan
Tyrann