I never liked it, but with C2x coming out, it's best to handle bools
properly. I haven't gone through all the uses of int as bool (I'll leave
that for fixing when I encounter them), but this gets QF working with
both c2x (really, gnu2x because of raw strings).
It was added only because FitzQuake used it in its pre-bsp2 large-map
support. That support has been hidden in bspfile.c for some time now.
This doesn't gain much other than having one less type to worry about.
Well tested on Conflagrant Rodent (the map that caused the need for
mclipnode_t in the first place).
And add a unary op macro. Having VectorCompOp makes it easy to write
macros that work for multiple data widths, which is why it and its users
now use (dst, ...) instead of (..., dst) as in the past. I'll sort out
the other macros later now that I know the compiler handily gives
messages about the switched order (uninitialized vars etc).
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).
I've had enough of this for the moment, but I'm pretty sure the test needs
some more consideration, and I'll probably forget about it if I don't mark
it.
I found wolfram's line-line intersection page and noticed their equation
for the time of intersection was rather different to mine. After analyzing
the differences, it turns out they produce exactly the same results (when
the lines are coplanar), but their method allows me to eliminate one dot
product (4->3). Not only that, but it turns out that their method works
equally well for skew lines (ie, non-coplanar).
mine:
CxA.CxA
-------
CxA.AxB
theirs:
CxA.AxB
-------
AxB.AxB
While unit normals aren't needed, they were too big for sane math. Now
epsilon can be used for the distance tests. One of the two new tests passes
now :).
When the trace stradles a plane in the current leaf, check the other side
of the portal, too, as it is possible that leaf will restrict the movement
of the trace.
All current tests pass! However, I can think of some situations (and I
already have a solution) where things will fail, but that's next.
The trace is moved as far into the leaf as possible without leaving the
other side of the leaf. This ensures that trace_contents is started from a
good location. There is currently a problem with traces that stradle a
plane getting, but this has cleared up all the current contents related
tests.
When visiting a leaf in box mode, use trace_contents() to get the highest
priority contents of any leafs touched by the box in the current location.
I'm now down to one failing test case, and it's an "allsolid" issue that
might be an incorrect assumption in my test case.
If trace is null or point type, or the hull doesn't have portals, or the
first node is a leaf, MOD_HullContents operates in point mode (exactly the
same way as SV_HullPointContents()). However, in box mode, all leafs
touched by the trace are checked for their contents. The contents field of
trace (a bit field) will indicate the contents type of all touched leafs.
The returned contents value indicates the most important contents:
solid > lava > slime > water > empty
The one's complement value of the contents type is the bit number of the
contents bit field. I'm not sure how useful this will be as getting the
amount of overlap is currently not supported.
The code itself seems to work now. There are still some problems: the box
faces are using unit vectors for the edges, or I should go back to unit
vectors for the portal edges; starting in a solid corner won't always work;
etc. However, that's just mopping up: the main algorithm seems to be
working.
If the trace hits a portal on the plane that brought us to the leaf, then
we actually are in the leaf (otherwise, we shouldn't be here and thus
should ignore the leaf). At least, that's my thinking.
Many point tests fail (but they're really using box clipping with a zero
sized box) and two box tests fail.
I got rather tired of there being multiple definitions of mostly compatible
plane types (and I need a common type anyway). dplane_t still exists for
now because I want to be careful when messing with the actual bsp format.
Bill Currie