The FPS thing is a tricky issue. It's even harder to effectively measure differences beyond "feel" because of the way Q2 protocol works. The more packets/sec you send, the lower your
reported ping will be - but it will still have the same latency no matter what FPS you use, it will just be reported incorrectly. Thus you can't really trust what your in-game ping is reported as.
The net/render FPS separation is a major change to the client so there will be a different feel to how Q2 originally works. In normal Q2, the event loop goes something like read input -> send packet -> render frame. With R1Q2, this changes and becomes read input -> apply input to the packet -> (send packet sometimes) -> render frame. So for every 3 or 4 rendered frames you are simply applying the movement to a packet that hasn't been sent yet. Then when a "packet frame" comes up you are sending the cumulative input of the 4 previously rendered frames in one packet. Obviously this has some limitations since your movements will no longer be 1:1 with input:packet. I've tried as best as I can to keep it as close as possible to the original, but short of increasing cl_maxfps it will never be the same.
This also has a lot to do with q2 physics on the server side. There exists an exploit in Q2 where a player can jump onto crates of 64 units when running at >= 100 packets/sec. Unfortunately many people regard it as part of gameplay now so it doesn't get considered a cheat as such. How this works is kind of hard to explain, but I'll try:
When you do a jump, imagine yourself doing a semi-circle movement. At the very peak of that movement, you are 64 units high. However the server will only apply your movement every time you send a packet, so the semi-circle is "sampled" every time the server gets a packet. This diagram should explain better:
The blue dots are what happens with a low cl_maxfps - less packets are received so your moves are not sampled as often. The green shows a high cl_maxfps - notice that at the very top of the circle there is now a sample taken, thus you are able to get onto a crate or whatever.
Unfortunately this isn't really fixable other than disallowing high FPS on servers so everyone has a fair playing field. It's just the way the engine works.
I really would advise against going over 100 cl_maxfps. Most of the original Q2 clients and modified clients limit internally at 100 fps, but due to R1Q2's separation, no such limit exists. By using cl_maxfps of 250 you will be uploading at almost 15KB/sec to the server!! Compare this to the 1.8KB/sec of a cl_maxfps 30 client and you realise you will be using a LOT of server bandwidth and CPU time for all those extra packets.
To be honest I've no idea why you are getting a better gameplay on R1Q2 server. I can't imagine how any of the small netcode changes I've made would cause such a drastic effect as you describe, but who knows, maybe they did
.
For now though to maintain the feel of other clients you are probably best using cl_maxfps 100 to be able to crate jump and exploit other physics bugs
. I'll see if I can improve how the lower FPS experience feels, personally I play with cl_maxfps 30 for a long time now and I'm quite used to it and it feels no different to normal clients now. But maybe not for you
. If you can explain how it "felt wrong" in more detail I'll see if I can focus on some kind of area that would be causing it.
Thanks for giving my client a try! Please let people know about it, especially if you know someone running a server, there still exist a lot of Q2 servers that are vulnerable to some major security problems by not running an updated binary.
Author