Thing is that frame rate would be extremely misleading here, since the variance is practically invisible with just frame rate. The frame rate would only match up the total amounts if all of the frames rendered in the same amount of time, which isn't always the case. I'd feels like I'm just repeating my self here tho…

Can you elaborate on this point actually? I don't understand what you mean.

Hang on a second. I thought we were arguing on the reliability of frame rate, but we're really arguing on whether frame time is the same metric as frame rate. I think I get your logic here (that since frame rate is a frequency, frametime can technically be derived from frame rate and thus be used to get the frame rate), but I just don't agree that derivative metric are the same as their parent metric.

If this turns out to be basic stuff, then sorry about that. I just didn't learn about this beforehand.

<rant>When people think of political parties, they think of the left and right party. Sadly those two parties are the only ones publicly recognized, which causes problems since if one side loses, the other gains control. There are far more political parties than those two, and if we can have more political parties to choose from, then may be politics won't be so fucking oppressive. </rant>

That is a huge oversimplification; there is more to this guides than just mastercomfig. I also recommend frametimes over frame rate and tell people that bad servers will cost you performance.

Good point…

I have to be missing something at this point. Frametimes can vary in each frame (e.g one frame could take 100ms to render while another could take 400ms, but 1⁄2 = 500 ms), so why bother deriving the frametime from frame rate when the frame time will vary anyways? I mean frame rate is counted over a second right?

It's right here. I forgot to set a download link for some reason…

Thing is that deriving frame time from 1⁄frame-rate assumes that every frame has rendered in 1⁄frame-rate seconds (even when assuming that the frame rate is recorded in instantaneous rates of change), which isn't always the case in reality. e.g 60 frames were rendered in a second. 50 of those frames each rendered in .2 seconds, while 10 frames rendered in .8 seconds. In this example the frame times are uneven, but we still get 60 frames so by deriving the frame time from frame rate, the frame time would be 16.6ms despite the actual frame times recorded being uneven. This is an oversimplified example so I'll probably edit this later.

I think I'm getting at what you were trying to explain. I do remember referring to the average frame rate when I argued that frame rate ignored any variations. Now I definitely agree that I should have been arguing with the context of an instantaneous frame rate counter, but I still don't think that just because a metric can be derived from another metric that means the two metrics are the same. I'm probably going to go search about this topic for my self to see if I can understand the argument there.

I'm pretty sure only the Source Engine has issues with full screen optimizations. I don't ever remember those optimizations causing any issues on Steam.

I'm 16 years old currently (will be 17 in 2 months and 17 days from this post) and I want new hardware. Unfortunately due to the current and estimate world state at the moment (fucking terrible), my motivation for job hunting has already sunk. I'd rather stick with shit hardware than suffer at retail, despite wanting better hardware. Help pls?

I was wrong when I said that frame time and frame rate were the same metric. They clearly aren't the same. You can't just derive frame time from frame rate (like frame time = 1⁄framerate) as that ignores any variations in frame time. Instead you have to record both frame rate and frame time.

I don't like being pretentious at all, because it's not fun; I just go nuts over incorrect grammar and improper wording.

Cool. Then I get to learn more about them. Even then I can easily get the information from higher education just through the internet alone. That's why I think college is a huge scam if you don't plan on getting into a STEM job.

I'm trying not to talk down or insult to anyone, but I guess I must have accidentally done so. Will look out for that in the future!

Explain? I always refrain from ad hominem attacks and rarely insult people in formal discussions.

You know this tampermonkey script could be expanded to be a filter list that blacklists bad posters/posts and removes them…

I learned this fact at some point, but I forgot about this until you mentioned it. Anyway yeah the correct name is GNU/Linux.

Heh. Hilarious.

(I really shouldn't have joined this forum…)

Just another reason why you should just use Linux (which is soooooooooooooooooo much better) instead of Windows/MacOS.

So that's the reputation I gained on this forum…

You have a point. Still though they shouldn't be limiting clientside network settings (or in other words the player's network settings).

The only problem I have with the new FACEIT servers is that they limit client side settings. They force the updaterate/cmdrate to 66 and as a 128 tickrate server, this is always a bad idea; Just set the maximum updaterate/cmdrate to 128 and leave the other limiting cvars alone (sv_minrate, sv_maxrate, sv_minupdaterate, sv_mincmdrate, sv_client_min_interp_ratio, and sv_client_max_interp_ratio). They enforce a minimum rate (or bandwidth) of 128 Kilobytes (or 1 Megabit), which is way too high! Can someone tell the server operators to remove these limits (by setting sv_minupdaterate and sv_minrate to 0)?