o All instances of LIBADD/LDADD have a corresponding DEPENDENCIES
specificatiion.
o libraries now use a lib_ldflags macro to keep things consistent
o duplication of source/lib names has been minimized (particularly in
the libraries; more work needs to be done for the executables)
o automake spec blocks have been organized (again, more work needs to be
done for the executables)
For now, only the glsl loader disables caching, but it stores the frame
vertices in GL memory, so its hunk usage is relatively lower (and will be
lower still when I get skins sorted out).
After getting in contact with serplord, I now know that the sw alias
loading was correct. Turns out the gl loaders was mostly correct, just a
mistaken subtract rather than add. And with that, I can implement alias-16
support in glsl. better yet, since all the work is done in the loader, the
renderer doesn't know anything about it :) However, I need to create some
16-bit models for testing.
Not all hardware can access a texture sampler from the vertex shader, and I
don't want multiple paths this early in the game. Now, vertex normals are
uploaded as shorts. Should be 14 bytes per vertex (was 10, could have been
8 if I had put the normal index with the vertex rather than st).
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.
It turns out that the box trace CAN get out of the solid from that location
(though a similar point trace can not). This is because of my decision to
allow non-points to touch a plane from either side without crossing the
plane, whereas a point touching a plane is always considered to be on the
front side of the plane as there is no further information to disambiguate
on which side of the plane the point is.
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.
When the portals are too big, floats break down and break the tests. This
might not be much of an issue in real maps, but my tests use "infinite"
planes.
Unfortunately, Pythagorus and binary don't play well together, so rounding
errors are inevetible when testing with a slope. However, 1e-6 seems to be
a good epsilon (printf's %g hides it nicely :).
