I'm hoping to get the next DirectQ release out tomorrow; no real performance improvements for you this time, but I have been fixing up some of the multiplayer aspect a little. The key thing is that .loc files now work again; the previous breaking of them was due to some code I had commented out while tracing through other problems with the ProQuake messaging system (this is the thing I had referred to some time back where the comment on the relevant part of the code was "added this").
I know that other ProQuake features have been requested many times in the past - stuff like team scores, match times, etc - but you're really going to have to take my word on this one and bear with me. The system is complex and it's not just something you can drop in casually and expect to work first time; especially not in an engine that's been as heavily revised as DirectQ has (and I don't just mean the renderer). Hopefully this latest change will have worked out most of the bugs and problems that have accumulated to date with it; if so I'll feel more comfortable pushing ahead with the next part.
One other thing I didn't get done was some required fixes for weirdness in the FOV code. For now you should just play with values until you find something that works well enough; the next one will do it right. I also didn't manage to revise entity alpha as time caught up while chasing other bugs.
As you may guess from my recent removal of 16bpp modes, the video mode list will have changed and your selected video mode will likely be no longer valid. I have a fix - of sorts - for this in place, but it hasn't really been tested in the wild just yet, so tomorrow's release will be an opportunity to see what happens. All going well you should get a 800x600 (or similar) windowed mode when you launch it the first time. You will then be able to go into the video modes memu and select the mode you really want.
Something I see on occasion is people complaining that Quake is taking too much CPU, that an old game shouldn't do this, and on occasion engine authors may even go so far as to put a Sleep call into their code to prevent this from happening.
Here's my take on it.
Quake is a real-time interactive application. Now, one of the features of a real-time interactive application is that it needs to respond more or less instantaneously to user input, and it needs to update it's display (and internal book-keeping) to reflect the current situation more or less instantaneously too. Otherwise it's no longer real-time nor interactive.
The only reliable way to do this is to keep the CPU running constantly. That way whenever anything happens it's ready to react. Minimum lag between the event and the reaction. This is important.
Now, most of the time when Quake is running it's actually doing nothing. Just spinning around in a loop waiting for a certain amount of time to have passed. Something cool about decoupling the timers is that you can now make some productive use of a good chunk of that "doing nothing" time, but that's irrelevant for this discussion, and the majority of time is still spent doing nothing.
So why not just send the CPU to sleep for a short while during these time periods? Here's where the trouble arises. Sleep function timers are imprecise; when you tell the CPU to sleep for n milliseconds it doesn't actually sleep for n milliseconds; it sleeps for n + x milliseconds, where x is a number that may be between 0 and infinity (in practice it's going to be around the 1-20 range). This is outside of your control.
So right away you're introducing a hugely significant element of imprecision and uncertaintly into your timing, and the end result is that Quake is no longer real-time nor interactive; every time the CPU sleeps there will be a certain amount of lag that you don't know in advance, that may cause you to miss frames, and that results in uneven response which only gets worse as the framerates get higher.
You as the player definitely do not want that, and that's why DirectQ will always chew as much CPU time as it can get.