If you've paid attention to DirectQ's FPS counter you would have noticed that it gave a rate of 71 FPS instead of the full default 72 in most scenes. I had noted a while back that this was due to a rounding error, and that I would fix it when I could have been bothered to.
Today I decided to bother, and after some digging the bad news is that I'm not going to fix it, but the good news is that I can now explain what's going on (which with hindsight should have been obvious).
Quake by default runs at a maximum of 72 FPS, which means that every 13.888888 milliseconds a frame will run. However, Quake also used a CPU performance-based floating-point timer which was quite prone to drift and unevenness on modern machines. Some time ago (one of the 1.7s I think) I replaced this with a millisecond-precise integer (DWORD actually) timer; the same as that used by QuakeWorld and QuakeII (I haven't looked at this part of the Q3A code but I would guess it's the same there too).
Now the thing about integers is that they don't accept values in-between. So rather than ticking over at the 13.88888 millisecond mark, DirectQ ticks over at 14 milliseconds (it can't at 13 because 13 is lower than 13.888888). This tick over at 14 milliseconds equates to a framerate of 71.428571etc frames per second, and as DirectQ displayed it's FPS as an integer, it got lopped down to 71. So there you go; the basic laws of numerics worked against fixing this, and DirectQ actually updates ever so slightly slower than Quake (but at the same speed as QuakeWorld/QuakeII) - what's 0.111111111 of a millisecond between friends?
For 1.8.0 I went millisecond-precise as far as I could, which unfortunately wasn't too far as QC and the protocol both require floating point time input in seconds. However any floating point drift will only last for 1 frame, and DirectQ is immune to drift and instability from your CPU performance counters. I have also now added a decimal place to the FPS counter so that you can see in more detail what's going on.
Two new features were just added. I know I declared a feature freeze, but if the guy building the engine can't make his own decisions on what goes in, who can? Anyway, they were fun and very quick to code.
The first is allowing for alpha in weapon models during regular gameplay by using values of r_drawviewmodel between 0 and 1; if this is considered "cheating" because it shows more of the screen, then so should r_drawviewmodel 0 be. A server that forces r_drawviewmodel 1 will always override it anyway.
The second is adding some extra range to looking up and down; you can now go the full 90 degrees in either direction by setting cl_fullpitch 1 (it's 0 by default for consistency with ID Quake).
The last remaining rendering glitch has just been fixed, which was that I needed to force a texture change if a VBO fills up otherwise we would have invalid textures and possible white-flash and/or binary garbage when running large maps with r_novis 1. The full and final 1.8.0 build is therefore pretty much ready to roll, but I'm gonna sit on it for a few more days in case anything last-minute comes in. Plus it will mean that I get to play Quake with it before you can - HA-HA!