Quake 2 netcode and tick rate

[silikone]

It is to my understanding that Quake 2 servers run at a tick rate of 10Hz. Now, this is of course an old game designed to support 28.8k modems, but the original Quake ran at 20Hz by default, and Quakeworld could variably send updates independently to each player. With this in mind, isn't this a downgrade? Are there any benefits of this approach?
Most importantly, is it possible to increase this rate while maintaining compatibility with vanilla clients?

[R1CH]

There isn't a way to increase it in a compatible way. I added experimental tick rate scaling to R1Q2, it can be controlled via sv_fps on the server and both R1Q2 and Q2PRO clients support it. However the general feeling was that it changed gameplay too considerably, eg the chaingun becomes ridiculously powerful when there wasn't as much built in latency.

[QwazyWabbit]

Another complication occurs when you consider how many mods exist for which we no longer have source code. Most mods, I dare say virtually all mods, used a hard-coded constant FRAMETIME in g_local.h that defines the time the mod expects the tick rate to be. The mods would need to change this compile-time constant into a function that would get the frame time from the sv_fps variable. If you don't have the sources you'd have to hack the mods in very many places in the DLLs to handle this.

You can send data down the pipe more often but if the game isn't thinking faster you're only sending redundant data, smaller deltas or smaller packets. What's the point of sending 20 or 50 fps down the pipe when the game is only updating at 10 fps?

[Jay Dolan]

The client has some issues with increasing the framerate as well. Namely:

 * Simulation time is hard-coded to 100ms frame interval, which influences model animations, particle trails, etc..
 * Stair prediction (interpolation) is also hard-coded to 100ms interval
 
Lastly, and probably the most harmful thing that I noticed in refactoring Quetoo to run at 40Hz, is that while the client will correctly parse all pending server packets at each client frame, it actually only _processes_ the most recently received server frame. At 10Hz, it's rare to receive multiple server frames in a single client frame, because most clients are running at 6x or 12.5x the server frame interval. It would only happen on choppy, poor-quality connections, which already yield a lossy experience anyway.

But at, say, 40Hz, with a 60Hz v-sync client, it happens all the time: a client frame will read two or more server frames from the network. What Quake2's client would do in this case, is basically drop the first server frame to the floor, doing nothing with it, and interpolating only the last received frame. This would result in missed animations, missed sounds, missed effects, etc.. It was actually really problematic, and took me a while to understand.

The solution I came up with for this is to ensure that every server frame is interpolated, even if its result doesn't make it to the screen. When parsing a new server frame, I check if the previously parsed frame has been interpolated. If it has not, I force a "lazy lerp" on it. This ensures that animation changes, entity events (landing sounds, footsteps, etc), ..never fall through the cracks:


https://github.com/jdolan/quetoo/blob/master/src/client/cl_entity.c#L242

Anyway, yea, there's really no way to change Quake2's tick rate without some serious surgery, and willingness to cut compatibility with binary-only mods.

[Irritant]

Jay that is really good info.  I refactored Alien Arena some time ago to allow for servers/clients to run anywhere from 10-120 fps tickrates, and did not know that about the netcode dropping frames.

I haven't noticed those issues with animations.  Not sure about the sounds, but I'm sure it will miss some given what you've said.  Will definitely look at this code.

[Jay Dolan]

You know what? I just checked the Quake2 source code, and Q2 at least handled entity events (footsteps, falling sounds, respawn, etc) correctly by dispatching CL_FireEntityEvents at the end of CL_ParseFrame. I must have moved that call to somewhere downstream over years of refactoring. Probably had something to do with introducing a client-game module (ala Quake3), or attempting to multithread the client.

 

There may be other instances that do still affect vanilla Quake2 as described above. I guess my only advice is to make sure your client correctly deals with ALL server frames, and not just the last one to arrive at any given client frame.   

[Irritant]

So Jay, here is what I've been seeing now that we have a bunch of servers out there running at 40hz:

For the most part, servers at 40hz run really well, I had no problems even at 120 ping on a server with 10-12 people, but this was an instagib match.  I didn't experience too many issues with regular DM either, all seemed good. 

Where I ran into problems was on a Chinese server at 250 ping, at 40hz I was getting a lot of hitches, and yellow bars on the netgraph.  At 10hz, it was smooth.  I'm thinking packets were coming in out of order, which I guess at that rate is more likely to happen with a connection on the other side of the world.  Either that or the server is using hamsters to power it's net connections(it was an Azure VM I had set up).

[Jay Dolan]

Yea, I mean, it sounds like the connection you had to that server became saturated with the higher packet rate. A lousy connection would probably do better with fewer, fatter packets than with 4 times as many packets that are, individually, a little smaller. Might be interesting to fire up a Quake3 server (30Hz, I believe) to see how that performs over the same connection.