relax.

https://i.imgur.com/vHgqg6K.png

Scroll up and read mastercoms' post, looks like you missed it

Because me having only 150 hours on spy is completely irrelevant from whether I'm qualified to talk about game performance?

the real secret to good performance is sitting and optimizing your own graphics config to make your rig play the game the best it can, it might not be fun and it might take hours but there isn't really a 1 size fits all solution to optimizing this game

There's an OS optimizations section. https://docs.mastercomfig.com/en/latest/os/windows/

Not everyone actually has the patience, programming and Source knowledge, or humility to be able to make a good performance config. The way I see it most players just shove in cvars with barely any research put into them without even bothering to save the changes to the video config. That's why I just recommend hunting down a good config made with thorough yourself.

Yeah I know about that. Point is that not all of the performance tips exist on your site documentation(, like reducing resolution and aspect ratio and changing the DNS server), and they're often scattered around the internet so they're not always easy to find. That's why I wanted to make a complete comprehensive performance guide.

oh no..

I get it man, you have a passion and you wanna see this through, but you don't have the knowledge base or time spent on the subjects you're talking about to provide the information that you want. You're just googling stuff and obviously you found some sources but they aren't good

changed from google to cloudflare dns, fps tripled, ping halved, tysm!!

There's a reason this kind of stuff has taken mastercoms years and thousands of hours to compile. It's good to see someone passionate about something like yourself, but the starting point for that should be doing your own research into the topic, not undermining someone who actually has done that work.

I'm aware of that which is why I'm quite willing to put in a lot of research into this guide. That being said I think that mastercoms might be better for this job actually, because she already has years of knowledge under her belt so the only to worry would be the production time.

insider preview of tftv user AimIsADick's performance guide

https://i.imgur.com/5CyC3VT.png

I'd just like to interject for a moment. What you're referring to as frames per second, is in fact, frametime, or as I've recently taken to calling it, frame pacing. Frames per second is not an efficient means of measuring performance unto itself, but rather a measurement pertaining to the number of frames generated in a single second, but does not take into account the amount of time it takes to generate a frame.

Many computer users are advocating for frames per second being the standard unit of the measurement of performance, without realizing the superiority of frame pacing. Through a peculiar turn of events, frametime has been all but erased from the internet due to FPS supremacy revisionists, and unbeknownst the the general populous, the glory of frame pacing has been veiled.

There really is a frames per second, and these people are referencing it, but it is just a part of the FPS agenda. Frame pacing is really at the heart of the matter: the unit of measurement in the game that takes into account the allocation of the machine's resources to generate a frame. The time taken to generate a frame is an essential part of any video game, but useless by itself; it can only function in the context of a running video game. Frame pacing is normally used in combination with the measurement of performance: the whole game is basically individual frames with a certain amount of time added, or frame/[time taken]. All the so-called "FPS" supremacists are really just pawns in a chess game.

I think I'm going to refer the synchronization of frames as frame pacing as that seems to be a better name for it. Anyway this is what I've been saying for a while, but no one except a few people got the message.

miles per hour is a very misleading metric. i measure my speed in hours per mile. its soooooo different and so much better!!!

shitposts these days just arent what they used to be

Strawman.

Yeah it's sad really...

What do you mean strawman? Miles per hour has the exact same kind of relationship to hours per mile as FPS has to frametime. It's identical.

Go look at what an fps indicator does, it's literally 1 over the last frametime. Here's cl_showfps for instance https://i.imgur.com/QNjUyPI.png

Actually I don't think it's a strawman but rather a false equivalency. I haven't thought through this yet, so I might be wrong. Either way there's still a difference in that comparison even if it isn't a fallacy. Miles is a form of distance and hour is a unit of time. Both give the exact same amount of information because at the end of the day the fundamental units that make them up (miles and hours) give enough information for the information difference to be nearly imperceptible. (e.g 5 miles per hour and 5 hours per mile both carry the distance traveled and the time it took, but not the variations in between the time/distance units.)

By contrast framecount and frametime, while they both are the same metric type (they're not literally the same metric), carry a clearly noticeable different amount of information from each other; frametime is the time it takes to render a frame which can be handy for tracing the issue to a bottleneck, delayed renders, or just slow processing power in general, while framecount is the amount of frames that can be generated in a specific time frame, which can only give whether you're getting enough frames in a second. A significant factor here is that frametime can will vary a ton in between seconds, and that variation is nonexistent in framecount per time, which is why I consider framecount per time as an inferior metric.

Honestly I should have just been referring to frame pacing from the start.

dude your guide is insane i just reached 800 fps in a pug

https://i.imgur.com/QHGd3px.png

only did 190 dpm so i think your guide fucked my shots registering or smth

Man isn't it lovely to get downvoted just because you said the Übersaw is overrated trash, or some other "controversial" opinion that no one bothered to actually read and think about?

-

one day you will realize it is you and not everyone else and that is the best case scenario

https://i.imgur.com/UtXZgJm.png

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.

-

dont talk about it, be about it. wheres the fucking guide??

Framerate and frametime are exactly the same metric, period. The 'rate' in framerate comes from comparing frametime to a set time interval (1 second, in frames per second). You can derive one from the other simply by taking its reciprocal, as that's all they are: reciprocals of each other.

The difference you believe you've discovered between frametime and framerate is actually you discovering the difference between instantaneous and average rates of change. Average framerate communicates the exact same thing as average frametime (they are the same), and instantaneous framerate communicates the exact same thing as instantaneous frametime (they are also the same).

You're looking at the difference between average framerate and instantaneous frametime, noticing that they are indeed not the same thing, and then saying that the reason they are not the same has to do with framerate vs. frametime when in reality it has to do with average vs. instantaneous rates.

It is true (as you've been saying) that having consistent frame pacing is important, but you can measure that pacing in either frametime or framerate, as they are interchangeable, measuring and communicating the exact same thing.

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.

When you're driving a car, the speedometer does not show an average of your speed over the last hour, despite reading "miles per hour".

And you can easily calculate hours per mile by taking 1 over your speed. This is just how units and math work.