Upvote Upvoted 0 Downvote Downvoted
mat_maxframelatency doesn't work anymore???
posted in Q/A Help
1
#1
0 Frags +

I posted about this command a few months ago, but people kept telling me it was some placebo bullsh*^ and it did nothing, which wasn't the case at all for me (It made a monumental difference for me, and I got my brother to try it out and he felt it as well). I opened the game today after a week, and it felt like it was responding REALLY slowly. After a reboot, I noticed that it was an "unknown command" in the console.

man fml.

I posted about this command a few months ago, but people kept telling me it was some placebo bullsh*^ and it did nothing, which wasn't the case at all for me (It made a monumental difference for me, and I got my brother to try it out and he felt it as well). I opened the game today after a week, and it felt like it was responding REALLY slowly. After a reboot, I noticed that it was an "unknown command" in the console.

man fml.
2
#2
4 Frags +

That's unfortunate for you. Fortunately, you seem to be the only person who noticed a difference.

For others who don't want to search for his past thread: http://www.teamfortress.tv/26008/mat-maxframelatency

pazertl;dr: mat_maxframelatency does nothing, and the engine is already tuned optimally for lowest input latency.

Judging by the name, this controls the maximum number of frames that the cpu is allowed to be ahead of the gpu by. This value is in frames, not seconds, so it's an integer, not a float. There's no difference between 0.2 and 0.9, because they both truncate to 0.

As of 2007, this cvar wasn't hooked up to anything, and there's no reason to believe it is does anything now. I believe it was replaced by mat_frame_sync_enable (cheat, default 1) when multi-threaded rendering was added to Source (mat_queue_mode 2). In short, mat_frame_sync_enable forces the renderer to wait for the previous frame to finish before it starts on the next one.

Either way, frame syncing is designed to reduce input latency at the cost of a few fps. If you had sv_cheats 1 and decided to set mat_frame_sync_enable 0, you *might* have improved fps, but you would instead be getting (potentially large amounts of) input lag.
That's unfortunate for you. Fortunately, you seem to be the only person who noticed a difference.

For others who don't want to search for his past thread: http://www.teamfortress.tv/26008/mat-maxframelatency

[quote=pazer][b]tl;dr: mat_maxframelatency does nothing, and the engine is already tuned optimally for lowest input latency.[/b]

Judging by the name, this controls the maximum number of frames that the cpu is allowed to be ahead of the gpu by. This value is in frames, not seconds, so it's an integer, not a float. There's no difference between 0.2 and 0.9, because they both truncate to 0.

As of 2007, this cvar wasn't hooked up to anything, and there's no reason to believe it is does anything now. I believe it was replaced by mat_frame_sync_enable (cheat, default 1) when multi-threaded rendering was added to Source (mat_queue_mode 2). [b]In short, mat_frame_sync_enable forces the renderer to wait for the previous frame to finish before it starts on the next one.[/b]

Either way, frame syncing is designed to reduce input latency at the cost of a few fps. If you had sv_cheats 1 and decided to set mat_frame_sync_enable 0, you *might* have improved fps, but you would instead be getting (potentially large amounts of) input lag. [/quote]
Please sign in through STEAM to post a comment.