mtasa-blue
mtasa-blue copied to clipboard
multitheftauto
Change max fpslimit to 500
Makes it easier to spot framerate issues. Default values are unchanged, and server owners still need to change the limit if they want to let people have higher fps.
I asked for these change a while back but for a far different reason. Still, even if new bugs appear because of unlimiting the FPS this should be a per server problem (since for years we had a lot of issues related to FPS and those never stopped anyone for using 100fps on their servers instead of the recommended 60/70fps, even worse for race servers on water races and such).
There is a way to make your FPS unlimited if you edit FPS limit in coreconfig.xml to be 0 and set FPS limit to 0 on the server.
There is a way to make your FPS unlimited if you edit FPS limit in coreconfig.xml to be 0 and set FPS limit to 0 on the server.
Just tested this and it's true... this is a bug isn't it?
There is a way to make your FPS unlimited if you edit FPS limit in coreconfig.xml to be 0 and set FPS limit to 0 on the server.
Just tested this and it's true... this is a bug isn't it?
No I was told about this feature by an MTA developer (can't remember who, probably ccw) for similar reasons to what this PR is about. I wanted unlimited FPS so could test FPS impacts of different scrips.
I think that increasing the maximum FPS limit is a good change on its own, even if it it's not necessary for debugging. With the advent of 144 Hz and higher refresh rate displays and several glaring high FPS issues being fixed, it makes more sense than ever to want to play MTA at 200 FPS and beyond.
Can someone explain, what is the point of having server-side fps limit right now? Is there any architecture/sync limitations that forces to use that limit? Are we able remove server-side fps limit and make it as client-side only feature after merging recent fps related PRs?
There is nothing wrong with a server side FPS limit, some servers want to make sure that FPS isn't over a certain limit to prevent a variety of bugs but more importantly there are some unfair advantages gained from higher FPS such as driving faster.
There is a way to make your FPS unlimited if you edit FPS limit in coreconfig.xml to be 0 and set FPS limit to 0 on the server.
Can be done at runtime too via console:
fps_limit = 200
run setFPSLimit(0)
fps limit of 500 is unreasonable more than 200 HZ monitors are already marketing placebo and there is no reason to support pointless power consumption limit to max 240/250, but everything above doesn't make sense anymore
EDIT: i forgot to add that i mean this only in case there is a way to make rendering fps indepdent which currently someone is experimenting on
Can someone explain, what is the point of having server-side fps limit right now? Is there any architecture/sync limitations that forces to use that limit? Are we able remove server-side fps limit and make it as client-side only feature after merging recent fps related PRs?
I think that increasing the maximum FPS limit is a good change on its own, even if it it's not necessary for debugging. With the advent of 144 Hz and higher refresh rate displays and several glaring high FPS issues being fixed, it makes more sense than ever to want to play MTA at 200 FPS and beyond.
fps limit of 500 is unreasonable more than 200 HZ monitors are already marketing placebo and there is no reason to support pointless power consumption limit to max 240/250, but everything above doesn't make sense anymore
This game was not made for such high framerates, setting it any higher than the current limits will have impacts on the internal clock and base GTA calculations, there is a whole project board related to issues caused by framerate.
The wiki outlines the majority of the problems that occur when the frame rate is increased too far beyond what is standard:
-
The higher your FPS, the longer it takes for you to start moving sideways while aiming certain weapons. At very high FPS, it may become impossible to do so.
As the most common issue, you should know that the breaking point for this bug is 70 FPS, so we recommend using a limit of 70 FPS if you intend to avoid this bug. Using 74 FPS is only recommended in non-combat focussed gamemodes (no gunfights) as the aforementioned breaking point of 70 FPS means that at 71 FPS, you will start getting a delay in moving sideways while aiming (having to hold the strafe key for longer). At 70 FPS, it still works perfectly.
-
74 FPS is the breaking point that opens the door to various more severe GTA bugs related to FPS and physics.
-
Physics of vehicles is effected, both high and low FPSes may bring their own set of unfair advantages. Speaking about the consequences of high FPS in this context, up to 70 or 74 FPS is considered safe (as any differences in physics, if they do exist to begin with as they theoretically should, are so tiny that they are unmeasurable and thus wouldn't affect racing results in practise). Anything beyond 74 FPS may cause impactful discrepancies.
-
Pressing the horn button to turn on and off sirens gets really hard at very high FPS. For instance, at 100 FPS, you are more likely to hit the regular horn 3 times (inconsistent) before eventually triggering the siren, besides taking a similar amount of tries to turn off the siren.
-
At very high FPS, climbing over certain objects will result in instant death. Example at: 2520.108, -1681.407, 19.406, 266
-
The higher your FPS, the more of a penalty in satchel throwing distance (up to ~10% at very high FPS) will apply.
This game was not made for such high framerates, setting it any higher than the current limits will have impacts on the internal clock and base GTA calculations, there is a whole project board related to issues caused by framerate.
Of course, maybe it doesn't make sense to increase the limit that much right now. But seeing how many FPS issues @Merlin is fixing lately, I'm hopeful that one day that will no longer be a compelling reason to not increase the limit.
Did you know he fixed the issue with moving sideways when aiming above 40 FPS some days ago? :smile:
I still think that server-owners should be the ones deciding whenever they want unlimited fps or not, even if the game breaks. For me, the only reason we had the FPS locked was the aiming, which Merlin already fixed (thank you btw).
GTA runs most of it calculations based on FPS, even the difference between 25 and 60fps is massive (and important in speedruns, for example), so going beyond 100fps doesn't seem that crazy to me, and, to be honest, there aren't that many differences between 100-200+.
If it lead to crashes then I would argue against. Considering that rn you can actually bypass this limitation (a thing I didn't know was possible in vanilla) maybe this change is unwarranted.
I don't see a big deal in merging this.. at the end of the day, it's the servers responsibility to deliver a playable experience. If they use extremely high limits and thereby opt-in to FPS related GTA and physics bugs, let them.. they will discover its not so smart and revert it.
You will get a group of users that like to identify FPS related bugs, and contribute to the bugtracker, to be fixed probably by @Merlin if he keeps up the good work.
That the possibility exists, doesn't mean its constantly going to be used to any detriment. Total control in the server owner's hands isnt as bad as it sounds for uncapped FPS limits.. heck, some servers may even deliberately choose risky FPS limits (regularly upping it to see how far they can go), so their users can bughunt for a while, with the results reported on our bugtracker. Looking at the past, CIT2 is one of the communities that would be on the edge to collect data.
// Edit (11-08): It's really just a matter of principle.. MTA already puts huge responsibilities in server owners' hands, its totally fine, let alone that we can't know what kind of plans people will have with MTA in the future (even if our development pace slows down/stalls), or which FPS related bugs they are willing to work around with Lua scripts to make room for something unique, which who knows benefits from very high FPS, ahead of us.. there should just be freedom. Same goes for the later reply by Merlin:
After thinking about this PR we shouldn't have an upper limit at all. If something breaks at a certain fps you should limit your server fps to that limit. But we should not set an upper limit just because there is a bug in one specific scenario. Which might not affect other gamemodes.
Sounds equally good to me
Btw, uncapped FPS is valuable for profiling performance, even on the server script & mods level, as you can extrapolate any theoretical impact on rendering far before you'd notice it on your own PC hardware, by looking at max achievable FPS output differences
@Merlin I thought maybe all your high FPS fixes might actually improve overall FPS (since some of the fixes are about too many effects being created for higher FPS) and I did a basic test with a build before any FPS commits and then with the newest, just standing in the same spot with FPS unlimited (using the trick I mentioned in earlier comment) and the results are: maybe.
I noted the lowest, rough average and highest FPS I saw, with the old build: 218 - 250 - 277
With the newest build: 238 - ??? - 291
I've put ??? for rough average because it seemed that the FPS was jumping around a lot more, but it probably was higher if a proper average had been recorded.
Do you think there any things that prevent FPS being even higher like collision processing being done every frame instead of every x milliseconds? Because I don't understand how a PS2 which has like 1% the processing power of a modern PC could handle GTA SA with all those peds and vehicles moving around on screen and get 32 FPS or whatever yet I go somewhere with plenty of stuff streamed in but only a few peds and vehicles on screen and my FPS would drop to 100.
Strafing breaks on ~250 FPS. Animation starts slighty glitching out. Raising limit to 240 would be safer.
@ArranTuna These fps patches just limit the amount of particles spawning. If you are on a server with a lot going on around you which might spawn particles this will most likely help you have more stable fps.
In singleplayer all driving cars are just moved on a spline over the road and just switch to real physics if you hit them. That saves a lot of physic processing. PS2 also has a very low render distance and not really many vehicles and peds on the streets.
Regarding your fps issues I would need to profile it to exactly know what's the bottleneck and if we could improve it. I can take a look at it if you can provide me a resource with a scenario which drastically reduces your fps.
What I found in a 120s profiling session that we spend 3% on calling 3 pool functions(0x5503d0, 0x550230, 0x550300) for the object streamer to check if we still have room for objects. That's done every frame. And these function just go over the pool and get us the number of used entries in the pool. I can patch that if you guys are interested in it.
What I also noticed is that grass rendering is slowing my game down really bad. Standing in the field near the zero point I get ~300fps. With grass disabled in the settings menu I get ~520fps.
After thinking about this PR we shouldn't have an upper limit at all. If something breaks at a certain fps you should limit your server fps to that limit. But we should not set an upper limit just because there is a bug in one specific scenario. Which might not affect other gamemodes.
What I found in a 120s profiling session that we spend 3% on calling 3 pool functions(0x5503d0, 0x550230, 0x550300) for the object streamer to check if we still have room for objects. That's done every frame. And these function just go over the pool and get us the number of used entries in the pool. I can patch that if you guys are interested in it.
Many players would appreciate that. If it's not too hard.
I've added more arguments to vouch for approving this change in an edit to https://github.com/multitheftauto/mtasa-blue/pull/2682#issuecomment-1207282789 and i recommend @Merlin to change it to uncapped
But we should not set an upper limit just because there is a bug in one specific scenario. Which might not affect other gamemodes
I already saw examples, like a server that runs a 2D arcade/action gamemode (view from above) which doesn't even resemble GTA SA, but uses MTA as a game engine and avoids the well known FPS bugs due to its nature and limited use of GTA movement features. Imagine they have reasons to use much higher FPS limits, let them be..