v6 progs expects .zero to be only 1 word. The code actually tried to keep
vector out of .zero, but it seems I'd rearranged the structure defintion
without updating the code that kills the vector field. Problem spotted by
divVerent.
Now it doesn't matter if you get 22 fps or 72, you jump the same height,
which actually happens to be slightly higher than the previous 72fps jump.
Effectively, you jump the height you would if you got infinite fps ;)
I got the idea from blender when I discovered by accident that quat * vect
produces the same result as quat * qvect * quat* and looked up the code to
check what was going on. While matrix/vector multiplication still beats the
pants off quaternion/vector multiplication, QuatMultVec is a slight
optimization over quat * qvect * quat* (17+,24* vs 24+,32*, plus no need to
to generate quat*).
This avoids sending invalid pose data to the renderer. The symptom was a
vertex array offset higher than the vertex array size. Discovered by calim
of nouveau while he was debugging a driver problem found by QF. Many
thanks.
One's an actual bug, the other a bit of error checking (not sure how
necessary it is, but it's in code that we don't /want/ to run, so it can't
hurt :)
While this particular tigger of the real bug was caused by 659d95221e
(hopefully fix both the "get stuck waiting for 3d" bug and the null
worldmode bug.), the real bug was lurking in the code since the dawn of
time (from sw32's perspective). This fix is as per LordHavoc's suggestion
(heh, despite the years, he knows his code), but I spent the time hunting
down the trigger to understand just what was going on.
It turns out that (0,0,0) is too close to a wall (probably on, but the
slight default offset is too close) and the above commit changed the first
rendered frame to be before the player origin was set rather than after.
This fix feels correct to me because noclipping around with the sw32
renderer would probably hit the same bug with a bit of bad luck. Thus
ensure the index resulting from zi never exceeds 65535.
Not sure if it actually works as the clients don't render the result
properly (can't see anything where the model should be), but the output
model does import back into blender properly.
While checking the shaders to see if there might be anything obvious to
work around the current nouveau shader issues, I found a 1 that should have
been a 1.0. I'm surprised it ever compiled.
Since qf does linear interpolation of verts, this seems to be reasonable.
Certaintly better than the rose-thorns I got because I haven't figured out
how to kick the auto-clamp.
I've decided to use property lists to define mdl control scripts. Some
names will probably get changed, and I still need to write code for writing
a plist, but the hard part is pretty much done :)
Note that this is the data block that holds the list of actual shape-keys,
rather than the shape-keys themselves. I'm not sure what it's correct name
is (it's just "Key" in RNA).
I really dislike this method of setting the name, but the use of "Key" as
the datablock name is actually hard-coded into blender's C code :/
Without fakeuser set, blender will toss out the actions on save and reload.
Converting to an nla strip might take care of that, but I haven't figured
out how to do that yet, so avoid any nasty surprised for the user.
Eye position, auto rotation, sync type and particle effects can now all be
edited in blender: both import and export do the right thing. The settings
can be found in the "QF MDL" panel of the "Object" tab of the properties
view.
Bill Currie