double +1 usually

if you don't have anything fancy like gsync and you don't worry about overheating, uncapped will always give the least latency

any magic number (like x2 or x2+1) is based off the misconception that your frame renders will roughly line up with your monitor refreshes. They don't, and even a stable capped fps has very inconsistent frame times (they just average out to slightly below the cap, but individual frames can vary significantly), so you're gimping it unnecessarily.

Now if you do worry about overheating, or you really want a consistent capped fps for some reason, anything above 144 will be mostly fine, though increasing it higher as long as it's stable is generally better.

chad uncaps

keep in mind that as your fps goes up, 1 frame increases mean less and less for the actual time latency

for example, a 60 fps cap vs 90 fps cap (30 fps difference) gets you 5ms less latency, while 144 vs 174 gets you 1ms

also, i would recommend having the highest stable cap you can get, so you have fairly consistent time steps of polling the mouse and such, while still having pretty low latency

Cap at like 800. The only reason to have a cap at all is to prevent the game from glitching out at extremely high frame rates. Otherwise the more frames the better.

Alright, I looked more into this. fps_max DOES produce a consistent frametime. It waits in between frames to get to the desired frametime.

HOWEVER, the way fps_max waits between frames seems to be horribly inefficient.

I think you should cap this to a high value that you don't reach, lower values are better (because it affects load times and in menus FPS, causing lots of power usage and frame spam).

so, is fps capped or uncapped better

what part of 'cap to a high value that you don't reach' don't you understand

Mastercoms and I discussed this a bit and experimented with it, and I figure it'd be worth sharing results here. I went as far as writing a program to roughly mirror what tf2's fps_max does (same method for frame limiting, but no frame logic or threading or anything like that). The model could be improved to be more accurate, but it's good enough to tell if frames are consistent or not.

Compared to the expected frametime from fps_max, individual frametimes would vary anywhere from ~3ms slower (under cap) to ~1ms faster (above cap). Over time, these would average out to slightly lower than fps_max (<1ms under). These numbers depend on a few things (what you set fps_max to does change these a bit, for one), but it's a significant variation in any case.

This is alright for most of fps_max's uses, since most of the time you don't really care about this variation. But monitors absolutely do, especially when you're talking about "matching frames to monitor refreshes." fps_max 2x or 2x+1 is based off this idea, and the idea doesn't work out in reality.

TLDR: fps_max isn't consistent enough for monitors, don't use 2x / 2x+1 or any other fps_max based off your monitor refresh rate. Mastercom's advice of being slightly higher than you can get ingame is what you should follow.

You just need to keep your fps below 1000, so you can go closer than 800. I don't know the details of the problem since I've never gotten close to 1000 fps, but it might already be fixed, or it might still be a problem with the variations mentioned above (so something like 997 might be safest).

As mastercoms mentioned a bit, your load times are affected by your fps_max -- things load faster if they have to spend less time re-rendering menus. Ideally there'd be another fps_max for menus (like in csgo and dota) but there isn't anything like that in tf2 currently.

thanks JarateKing, your posts are always informative and you make some really cool stuff