+1
Not sure who suggested to allow fps to go a bit over fps_max, but it was very bad suggestion.
@alfred-valve, please revert that change, let fps be always equal or below fpx_max. If there are some issues with rounding for cl_showfps 1, then better use ceil for that.
We are very customized with previous behavior of fps_max.
Also may be you will consider issue #1218.
Thanks.
This is indeed a duplicate of https://github.com/ValveSoftware/steam-for-linux/issues/1218
No, it is not. This one mainly about capping of FPS with fps_max variable.
At least, let it be so. In hope this capping will be fixed. Or will have to make separate issue on that.
@LevShisterov Could you explain.
@r3n4m3, explain what?
i dont understand, why that topic is not duplicate?
It starts with "net_graph shows the exact value of fps_max. Rather than fixing the value in cl_showfps, you increased the fps so it would display a convenient one - this is incorrect".
I just wish this one to be fixed.
am I understand you correctly, are you against to show wrong FPS? not against a large number of FPS?
@r3n4m3, for your pleasure: #1706
Yep, I want fps_max to cap fps correctly.
I just hate the fact that you guys removed the 100 fps limitation.
For CS MODS like KREEDZ, HNS it's crucial to have 100 fps, now i'm forced on 101 fps because of the 3'rd part plugin named (uq jumpstats) and the movement it's slight different.
Please block the fps to 100 back!
I have a fix for this, as @AnAkIn1 suggested accruing the timing slop in CL_Move fixes the issue. I am still considering re-instating the FPS cap however, too many people appear to have broken video card drivers where setting Vsync is ignored.
@alfred-valve "I have a fix for this, as @AnAkIn1 suggested accruing the timing slop in CL_Move fixes the issue."
I hope this includes the fire rate too. I'm glad you guys found a solution, I'm looking forward to test it.
it is steel not working good. Shooting timing is FPS depended and speed after landing.
I propose to make check compliance: new changes and compare them with the calculated physics at 100 frames per second. To avoid confusion and to make sure that everything is done correctly.
I believe that developers will be able to help us in this.
@r3n4m3, better create separate issue for that.
Also I am afraid it will not be done because requires not just few code line changes.
net_graph shows the exact value of fps_max. Rather than fixing the value in cl_showfps, you increased the fps so it would display a convenient one - this is incorrect, and can be easily seen with software that detects FPS, like Fraps.
FPS affects the game speed of the client. The following FPS values made the client faster than normal - 125, 250, 333.3, 500 fps. Anything above that exact frame rates, makes the client behave like it's slow motion. Try fps_max 501 and you'll see. Now with this update, fps_max 500 behaves like 501, which makes the game extremely slow.
Here's a chart that represents what I'm saying:
![Measured]()
This itself is a bug that heavily affects the game. Because this is not only about moving, but shooting as well. This is what should be fixed, as it's a "legal" way of moving faster and shooting faster than your opponents.
I also noticed that this update removed (at least visibly) the cape of 1000 fps. FPS now can go over 2000 and so on, but anything above 1000 makes you heavily stuck while moving - one jump can take like 30 seconds.