Frames? No frames?
Framerate means more than just how smooth your picture is – it can also have an effect on the precision of your controls, and in some circumstances, on the physics of the game. Here’s how I understand things to work.
Clients and servers
One of the central features of the Quake engine is that it works with a client-server architecture. At one end sits the client. The client receives input (in the form of commands, including commands to do with movement; and also some extra stuff such as the player’s orientation) from the player, and sends it on to the server. The server interprets this information (and possibly other information coming from other clients), and works out what happens to the player according to the rules of physics built into the engine and the
progs.dat. It then tells the client the results. This transaction happens even on a single machine when playing single-player Quake; in this case, a single machine acts as both client and server.
The other thing that the client does is render the display according to where the server says things are, and according to the map
*.bsp that it has. (Lag in the display is the delay caused by waiting for the server to come back with this information. Client-side prediction in net play is just the client guessing from its own incomplete information about the game what the server is likely to calculate ahead of time, so that it doesn’t have to wait for the server response before it displays. Of course, when it gets it wrong, the correct information can be a bit surprising, so things can appear to happen without warning.)
Drawing the Quake graphics takes the biggest part of time needed for the game cycle. You’ll find that it also takes a variable amount of time depending on what is being displayed. This means that the client framerate depends on how fast the screen is displaying. Now, the client’s framerate is also the rate at which it can send commands to the server. So for the best precision in control, you want as fast a client framerate as possible.
Zigzagging, for example, is mostly dependent on accurate controls, so the client framerate is the one to watch out for when zigzagging.
If the server and client are on the same machine, then the server framerate and the client framerate are one and the same. If one runs a
-listen server, then the server framerate will be related to the framerate of the client on the same machine. But a
-dedicated server runs at a rate independent of all its clients. And since it is the server that calculates the physics that control the game, when a variation in this framerate causes a difference in behaviour, then it is the server framerate we ought to be watching. Wall-hugging is dependent on the minutiae of these physics, and so it is the server framerate that needs to be considered when talking about wall-hugging.
There are two ways to present a framerate. The way that is most coherent with the English language, and that is commonly used to describe how fast a game or piece of hardware runs is to measure it as a number of frames per second, or fps. On recent versions of QuakeWorld, you can get your client to display the framerate in this way continuously above your status bar by setting
However, for the most part id tended to use a different terminology: they measured how long each frame lasts. In this article, I’ll refer to this as the frametime rather than the framerate. However, the Quake console variables
sys_ticrate both measure things from this point of view; probably they should really be called
sys_tictime. Of course, the framerate and the frametime are just reciprocals of each other; framerate = 1 / frametime.
Normally (i.e. by default),
host_framerate is set to a special value of 0. This value means that the engine should match the rate at which time in the Quake universe proceeds with the rate at which the player sees it proceed in real life. Thus if some frame takes 0.04 seconds of processing time to compute, Quake will tick its internal clock along by that amount, so that “Quake time” has also progressed by 0.04 seconds.
However, if you set
host_framerate to be something other than zero, then “Quake time” instead advances by this amount for every frame displayed by the machine. As a result, if you set it to a value that is greater than your real life average frame time, Quake time will appear to progress faster than normal. If you set it to a value that is less, Quake will have run slower than normal. (This is how unscrupulous people do slow-motion cheats in single-player Quake. More usefully, it also lets you play demos in slow-motion or fast-forward them.)
You can use
host_framerate as a client when talking to a server to ensure that control commands are stamped as having been sent some exact period of time apart (rather than the real time, which can vary as your client struggles to display different numbers of brushes and so forth.) This accuracy allows such things as reliable 180 degree spins, and consistent zigzagging. However, if your client is talking to a server and you let your “Quake time” get too much out of step with the server (which will probably be running at the default rate) then strange things will appear to happen from your point of view, and eventually you’ll lose the connection. So, you have to reset
host_framerate to 0 every so often to allow your engine to realise what the time should really be.
(Thanks to Matthias Buecher for his nice explanation of “Quake time” and his investigations into using
host_framerate on a remote client.)
Recall that the server framerate is important to us because it determines how often the physics calculations are performed: this is not noticeable for most of the behaviour in the Quake universe, but it it very relevant to wall-hugging.
In normal Quake, the server framerate is controlled by a console variable called
sys_ticrate. This measures the amount of time each frame should last, and its default value is 0.05 (that is, twenty frames per second.) Most server administrators don’t bother to change this variable; if they do, they tend to decrease the framerate to 10fps by increasing the variable to 0.1. This gives the server more time to process each frame. If for some reason the server machine can’t process everything in time to keep up with the framerate specified by
sys_ticrate, then the server will just run as fast as it can manage; but if it has plenty of time (as is normally the case, especially with a
-dedicated server) then it won’t increase the framerate any further, but keep to the
Therefore NQ servers tend to have reliable framerates, and you may be able to guess what they are, but they are likely to be relatively low.
In QuakeWorld, the server runs as fast as it can, just like a client normally does. The less work it has to do, the faster it will go and the greater the framerate will be. Thus QW servers tend to have slightly less reliable framerates – but still, their workload is fairly consistent and so they don’t vary that much, and they also tend to run a bit faster. What the exact rate may be will be harder for a remote client to guess, though.
I don’t believe there is any way for a remote client to query the server and discover what the server framerate is. (The Quake-C variable “frametime” is supposed to keep track of the value of the the server frametime, but one can’t run a client-side mod to look at this when playing on a remote server…) If anyone does know of a way to read or to take a good guess at the server fps from within the Quake client, I’d be pleased to hear from them.
My thanks are due to Zoid for answering a few technical queries relating to this footnote. Any errors remaining in my understanding and in the above explanation are my own fault, though!