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.
3 comments:
I've thought a nice middleground for the CPU usage issue works like this ...
1. If dedicated server. Sleep when applicable. No input issues and it helps if multiple dedicated Quake servers are running.
2. For a client ... sleep when applicable if
a. no game is running (CA_CONNECTED is false)
b. A demo is playing (cls.demoplayback is true)
c. Client is in the menu (keydest is menu)
d. or if it has been 1 minute or more since the last keyboard or mouse activity if in-game (CA_CONNECTED is true)
There was immediate negative feedback when I very briefly had ProQuake.
aguirRe's Enhanced GLQuake uses these kind of rules:
1. Never sleeps during demo recording or demo playback (!). He says "Otherwise demos tend to be a bit shaky".
2. Never sleep during a timedemo
3. Doesn't let the client sleep if last sleep time was less than 20 milliseconds ago. "Don't sleep too often"
A note: back when I was playing with FlashQuake, I discovered that Flash has no way to "sleep" or yield the CPU so I had to render the host_sleep cvar inoperative in Flash. No wonder Steve Jobs didn't like the idea of Flash on the iPhone.
There was immediate negative feedback when I very briefly had ProQuake default host_sleep 1.
^^ finished the unfinished sentence
I actually think the default sleep rules in Quake (dedicated/paused/not focus) are quite fine; the only things I added to those is to bypass SCR_UpdateScreen calls if not the focus (IM clients ran really poor otherwise) and throttle FPS back to 72 if the server pauses.
I recall that DP experimented with sleep rules for your a and c conditions and ended up removing them because players were complaining about laggy and uneven input.
I like your idea of sleeping if no input has been detected for a certain amount of time; that's neat.
Post a Comment