Here's an interesting problem. By default Quake runs at a maximum of 72 FPS, and all physics, sound, input, rendering, etc can run no faster than this rate.
Now, it's common in modified engines to find a host_maxfps (or some variation on that name) cvar which allows the maximum to be adjusted. It's also common for to adjust this upwards in multiplayer.
However, a problem arises when someone who is primarily active in multiplayer uses a singleplayer map or mod, and has their max FPS set to above 72.
Because Quake's physics are framerate dependent, running at faster than 72 FPS in singleplayer causes things to start behaving really strange. Really really strange. This can be observed on the first elevator in e1m1, the first YA secret in e1m4, and practically anywhere else.
Sometimes it can even kill you - check out the elevator from the river up to the GA area in e1m1, for example.
This is obviously undesirable, but what's the solution? Decoupling the server framerate from the client framerate is one option, but that's fraught with danger. At the very least it would require extensive testing and mistakes being made along the way.
What I'm thinking here is to lock singleplayer games to a maximum of 72 FPS, irrespective of the value of the max FPS cvar. The problem is avoided, multiplayer fans can still set it for multiplayer games (and it's value won't be stomped over if they ever switch to singleplayer), and nothing gets broken.
Any opinions or feedback on this proposal are welcome,
Sunday, January 23, 2011
To 72 FPS or not to 72 FPS, that is the question
Posted by
mhquake
at
8:11 PM
Subscribe to:
Post Comments (Atom)
15 comments:
Sounds good to me ;)
It seems to me that uncapping the FPS here causes more problems then it solves.
k, this post is prolly about RMQ, right? I don't remember if this is already set or not in DirectQ... kinda got deja vu reading this
You should probably rename the CVAR to something with multiplayer or non-listen-server in it, then.
I'm actually planning it for both engines; I've talked about 72 FPS with DirectQ before, but that was in relation to the timer, and the fact that 72 doesn't divide into 1000 evenly.
Renaming the cvar would break compatibility with other engines so - although it is a good idea - it might not be desirable.
At the risk of paraphrasing a hoary old standby of geek culture, I really think 72 fps ought to be enough for anyone. Who's desperately pushing for more than 72 fps?
It's not so much about people pushing for more than 72 FPS as it is about protecting people from accidental misconfig that's fine in MP but toxic in SP. There are plenty of valid reasons for going higher than 72 in MP.
why is this not a problem in mp? or do you mean it's not a problem when the server is running remotely (and presumably capped at 72?)
In that case you would want your same logic to apply when someone is hosting a listen server.
if (sv.active)
{ Ignore fps cvar }
else
{ Use fps cvar }
The issue matters and is quite real. I myself being a multiplayer type had weird elevator kills me issues ages ago where I blamed the map.
And no ... 72 is not enough FPS in multiplayer. Mouse smoothness and responsiveness is directly related to frame rate. So is keyboard input, but it is less noticeable. And ping is related to framerate due to timing.
Remote servers are naturally capped at 72-fps and run the physics and NetQuake uses the pure client-server model so the client gains input smoothness with no physics weirdness. Really, NetQuake should have the client and server operations separated. In fact, if I recall, Spike's CSQC demo which I did a test implementation in aguirRe Quake *did* separate client and server operations even in single player (!!).
k, kinda off-topic here, but...
MH, do you know of Mumble(online voice-chat program) and/or the positional audio feature it has?
It can use a plugin with a game(whose source code has linking code added) to modify where you hear your friend's voice based on where their in-game avatar is. I think it's pretty cool, and would be a sweet feature for coop or DM games. Their source code to link to the plugin seems to be fairly basic, but I'm a really noobish coder so I have no idea of what kind of work it would take to add this to your source code. Linking code
no objections
If I'm understanding this correctly, decoupling the server frame rate from the client frame rate is the optimal approach (because it allows for clients to surpass 72 fps, which some might desire), but locking the frame rate is the easier, less trouble-prone approach.
Given that I always play with vsync and that I have a 60 Hz display, this won't affect me. But I'm wondering where I'll stand when/if I invest in a 120 Hz (or higher) display. I'd certainly like to be able to run the client at the display's refresh rate with vsync enabled (even if double the refresh rate has little advantage in the perceptible "smoothness" of the rendering), and if there's a cap, that won't be feasible.
Given that, the more difficult approach seems like the right one, but I can definitely appreciate a lack of interest in spending an inordinate amount of time on features for the 'edge cases'.
" why is this not a problem in mp? or do you mean it's not a problem when the server is running remotely (and presumably capped at 72?)
In that case you would want your same logic to apply when someone is hosting a listen server."
Correct on both counts. Baker nailed it in his response basically; right solution, right description, nothing more I need to say there.
Other stuff.
Voice chat is a nice idea, but I won't add anything that requires a plug-in, and I'm quite conservative when it comes to DirectQ in particular.
Vsync and refresh rates are a problem. Hoping that a real decoupling solution will have emerged by the time it becomes a real issue, but if not locking at 72 and preserving the correct physics remains preferable. If the worst comes to the worst there are other options (like injecting dummy frames to the renderer).
if the framerate breaks the lifts in single player, its going to break the lifts in coop/deathmatch on those same maps.
limit the tick rate of the server. its the only complete solution - especially as a server's packet rate is tied to how often it runs physics.
Quakeworld players like really high framerates, maxfps 480 or so, because multiples of the monitor refresh rate make things much smoother than 1.2 or so, which will give a stutter every 5 or so frames, where two sets of movement happened instead of 1.
or you can use vsync... but then you're stuck at 120.
its not just for twitch speed. smoother is nicer. :)
"if the framerate breaks the lifts in single player, its going to break the lifts in coop/deathmatch on those same maps."
It depends on the server. In a typical multiplayer setup, the server and the client are running on different machines; the client can run at whatever FPS the player likes but the server will be running at 72. Physics is performed on the server, so hence the fact that they don't break in multiplayer.
Get your local friendly server admin to increase your QW server's FPS to higher than 72 and watch things go crazy. You can even try this one at home for yourself.
In an SP setup the client and server run in the same process, and NQ architecture requires them to run in lockstep. Hence the trouble.
Post a Comment