After discussing things with Spike of FTE, it seems that not many clients
handle zero length mvd packets particularly well. While it the skip code
might be useful for qtv, getting the packets into one but not the other
seems to be not worth the effort at this stage.
There are some problems with menus and the console messing up the key_dest
state (they assume console/menu or game, nothing else), but otherwise
things seem to work.
in_bind_imt is now gone. I guess mercury was right in that it was a poor
design. However, it was (and still is necessary) to support "bind" and
"unbind". Now, instead, they work only with the IMT_MOD table. IMT_MOD sits
below IMT_0 in the imt hierarchy. If the key is not bound in IMT_0+, then
IMT_MOD will be checked. This way, "bind" and "unbind" can never mess with
a user's more sophisticated binding setup.
The backquote is not always usable for toggling the console, and the new
bind system doesn't automatically bind a key to both game and console imts
(by design). Thus create a cvar that allows the "always works" console
toggle to be specified in eg $fs_globalcfg. While I'm at it, do one for the
menus, too.
If the default sound device does not support mmap access, retry with
plughw. However, assume the user knows best and do not retry if snd_device
has been set to anything, including "default".
QF alsa support now works out of the box with pulseaudio.
Due to quake's original sound engine using a push model, the actual place
to which the sound data should be written is not necessarily where the
"hardware" dma cursor is, but rather where the last write finished off.
Thus, the correct output location is indicated by snd_paintedtime rather
than snd_shm->framepos.
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.
