Open r3n4m3 opened 11 years ago
There was a graph mentioned for Jump Times in one of the many bug reports for this issue.
I wanted to make it aware that Mirvin Monkey (who has been making maps for TFC since the early days) was the first person to discover this phenomena back in ~2000. He re-published the report again for legacy purposes a few years back on fortress-forever's site.
http://www.fortress-forever.com/fpsreport/
The issue is that forcing FPS at 50 no longer actually forces the FPS at 50.....mine appears as 50.5.
Others that swore by 101 or 100 are getting bad values as well.
This does affect gameplay drastically.
If you want to test it without the code, jump into a CZ server, force your FPS at 50, and unload 100 para bullets and record it. Now change fps_max 49 and unload another 100 bullets...record that audio too. There is a huge, drastic difference in the milliseconds between audio peaks that should not be ignored as trivial.
Sounds are different, true, but actual difference is not so big - less then 5-10% on normal fpses. For sure it could make the difference in question who will put last bullet and better this to be fixed. But at least in HLDM skill gives you more frags then small speed difference.
Actual difference is huge. An mp5 in CZ empties in seconds, and you get 2 extra bullets in comparing 50 and 51 fps. The para firing rate is even more noticeable.
Also, keep in mind that this firing rate isn't just about those 2 extra shots also. This affects bullet spread, recoil, etc. Messing with fps changes the entire feel of the game.
Everyone I knew was playing with settings that would work well with fps forced at 100. This update made their normal fps go above 100, and they would experience game/engine lag. Telling them to do fps_max 99 made their game much more playable. In short, fixing this one problem and having fps_max be accurate again will slow down lots of complaints, if I were to guess right.
Yes, if fps_max will be again give exact fps amount, it will be better. You have to set it 0.5 lower, i.e. for 100 fps you have to set fps_max 99.5. Also, I think you are for nothing comparing 50 to 51. For good play you need fps more then 100. (In HLDM at least). So better to compare fps you are playing to some reference fps (where you have fastest shooting rate). Yes, 50 fps gives fastest shooting rate, but I hope you are not playing on 51 fps, are you?
Bug #802 is the hl1/tfc fix for the firing rate problem, it needs porting to CS.
im curious as to whether this has been fixed and implemented into the beta ? for a lot of league play fps is currently limited by servers to try and minimize any fire rate advantages, but for some players this limiting results in an unsmooth visual experience and is a deterrent for some players, it would be awesome if we could use high fps without it affecting gameplay
I was away from my gaming PC for a while, and now things have gotten even worse with this problem.
We already can't set fps_max to 50 (still have to use 49 which turns into 49.5), but now firing rates are totally hosed at that number. Weapons that would have seen a difference often don't produce a sound or register a shot. I could unload an MP5 and have only 10 of the 25 bullets actually register server-side.
CS 1.6 Demo with this issue http://rghost.ru/48204115
Just adding my two cents here, if my fps_max is limited to 100 and have higher refreshrate than fps why does recoil become unstable? Or is this just normal with any game?
OS: Windows 11
Game: Counter-Strike 1.6
Protocol version 48
Exe version 1.1.2.7/Stdio (cstrike)
Exe build: 01:03:30 Dec 1 2023 (9899)
I came here from #81 regarding 'Jump-Lag' on CS 1.6, it would be nice to see this long-awaited issue addressed. Modern monitors now have greater than 60 Hz refresh rate, so players may use fps_max
greater than 100
to match their monitor's refresh rate, they can't do this without unintended consequences.
The player's movement acceleration (immediately after jumping) is being affected (slowed down) by an increase of the frame rate. This means that the time it takes to reach maximum velocity (accelerating immediately after jumping) is becoming slower than intended, when the frame rate is increased, basically the acceleration curve is altered. Specifically, the initial speed immediately after jumping becomes slower, then rapidly increases, reaching the maximum velocity.
Pay close attention to the ground forward run acceleration after the jump.
https://github.com/ValveSoftware/halflife/assets/16103757/4df95278-b706-4aa2-8fee-01d0539619a6
https://github.com/ValveSoftware/halflife/assets/16103757/5d53fa49-710a-46cb-acfc-7e749da23213
In continuation of this changes https://github.com/ValveSoftware/steam-for-linux/issues/1704
Physics still 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.