I found the FramerateCap property in UserGameSettings.
It was hidden in the documentation, so I wasn’t aware it already existed.
However, I can’t read it.
I don’t understand why Roblox blocked not only writing but also reading it.
I found the FramerateCap property in UserGameSettings.
It was hidden in the documentation, so I wasn’t aware it already existed.
However, I can’t read it.
I don’t understand why Roblox blocked not only writing but also reading it.
Your use case for wanting access to reading it and writing to it is to give your players a worse experience. It’s not a strong use case for such a thing. Not all your players will be able to run 240 fps or 144 fps, however not all players could run 60 fps before either. If you really want to even the playing field by bringing players’ experiences down, you’re gonna have to do a lot.
Players who have better hardware are going to have an advantage and it’s okay. It’s always been this way and probably always will be this way.
you’ve gone too far
Sure its an advantage, but there’s a difference between a fair advantage and an unfair advantage.
Listen to what the dude above me said, its basically like saying that slicing the pie is cheating since you are getting 1v1s instead of fighting every player at that angle, and you’re basically trying to make people peek the full angle exposed.
Not to mention you can’t cap player’s refresh rate so there is really no need for this as they will still have a good hardware advantage, so capping fps is just gonna make it look bad for your players and inconvenience them.
They can lead to very bad motion sickness, as the camera stops syncing with your head position
Finally, I’ve been waiting for this feature for so long!!
I feel like the given use case did not hit the mark.
For me, I would love for this to be exposed for the following reasons:
Performance improvements. Usually I rely on the getting the users graphic level for hiding objects that are just details, but this doesn’t always work. Sometimes, players set their graphics level to medium while preferring higher framerates for a smoother experience. Some players also like the classic look that low graphics level has. Exposing their preferred framerate gives me more control over how to optimize my experience at run-time.
Analytics. Knowing the preferred framerate of players can be used as a tool to see if that framerate is being achieved or not. For example, a player prefers 120 but is only getting 95. Being able to automatically see where their frames is dropping and if it’s by a large amount to what they prefer would be possible. A user could have 60fps but usually get 240 on other parts of your map or even in other experiences. Seeing the preferred versus reality is a good tool.
Disadvantages between users and their framerates. This was mentioned in another use case but was said to not be good enough. I feel like that’s a mistake. Roblox, in my eyes, has a cage-y view on what features to implement. I feel like this is one of them. Unity, Unreal Engine, GameMaker Studio, and even Phaser (lol) all have access for setting and getting player framerate.
I would really appreciate a reply.
See this is a valid reason that I support, and some decent ai can probably be used to remove certain tagged objects that are unneeded aswell
I dont feel like you should be able to cap a user’s framerate for them, and you shouldnt unless its for a certain aesthetic
Or if it provides an ACTUAL advantage, for example, with the way rex: reincarnated works higher framerates will make you mine faster, so they had to cap it
I actually do have a use case. I am making a very performance intensive voxel game and I throttle my functions and schedule them precisely to avoid frametime overruns. I do need to know what FPS setting the player has selected, so I can adjust the allowed execution time. Even if the players PC cant handle said FPS, they will just lower their setting until their PC can handle it. Otherwise ill need to add a manual FPS selection to my game. Which is definietly not the end of the world or even bad, but would be nice to have it do it automatically.
A player-controlled setting to dynamically lower FPS would be nice, too. I worked really hard to optimize an experience to fit into 60 fps, and since roblox doesn’t provide a way to run code in the background, the ~3.5ms my pathfinding updates take on top of the 4+ ms BulkMoveTo takes plus time used by animation and physics and everything else means it will stutter horribly at anything above ~100fps even on a powerful gaming rig (which is what those timings were taken on). Asking every user to change their settings to play my experience is excessive, and an auto-adjust setting that lowers FPS after noticing the cpu-bound stuttering would make more experiences playable without constantly changing settings.
I think this would actually be better in the Creator Hub analytics, as you get all the benefits of the analytics there such as device type, average memory, and other stats which can all be combined to accurately depict what the performance of your games is!
Frame times should not be controlling execution times and that is an awful way of programming. If someone is lagging, it would be much slower for them. If they are cheating, they can speed it up. Change your system buddy.
It would be nice if there was an option for custom framerates as well, I have a monitor that only runs at 75 fps, so I am either wasting power using 120 or not using all that is available with 60
The only thing I control is the Voxel generation and load/unload ops. And the time I set is a limit not the time it takes to complete. I said allowed execution time not the execution time. Try doing voxel ops without this and you will have frametime overruns. This allows most PC’s to run the game lag free (except if your GPU can’t keep up, thats another issue however) since the scripts will yield till the next heartbeat if it reaches the execution time. The only downside to this is terrain loading/unloading will be slower and sometimes visually unpleasing on lower end devices.
Before you ask I use every optimization you can think of except greedy meshing because my textures are applied onto a meshpart as an assetID texture and you cannot greedy mesh those at least without writing horribly complex algorithms for marginal gains.
If your system is generating terrain using heartbeat, you already know how fast it is going: as soon as a frame is drawn on the client. You don’t need a manual FPS slider or anything like that. This use case is absurd.
Even with these use cases it is still extremely unlikely we will ever expose an API for intended/expected framerate.
I love this update, but it begs the question: Will we eventually be able to run games at above 240 FPS without FPS unlockers with the issues about that being sorted out? This affects all players, and I know some people who do a lot more First Person Shooter type games that crave for frames above 240.
Probably not any time in the near future.
Running at framerates higher than 240 fps would require Roblox to detach the physics engine from the framerate and make it operate on a tick based system instead of running physics x amount of times each frame this would be a large scale change for a minority of players to be able to run Roblox at above 240 fps.
Your high refresh rate display still has benefits in the form of lower pixel response times improving motion clarity even without a high frame rate.
In FPS games particularly, people want higher FPS. Aside from feeling smoother it’ll render the frames much faster and give less response time at the cost of screen tearing which isn’t a big issue. On a side note it appears Roblox has quite a performance issue with the lastest updates.
You do realize that the fix to make higher fps possible actually adds a slight delay in fact its the same delay you would lose from making the framerate higher than 240 the current max framerate of 240 is perfectly synced to the physics engine all you would gain is smoothness but at that point Roblox would be better off supporting frame generation instead of actually rendering more frames.
tldr: To achieve higher framerates would require more latency added therefore negating the biggest positive of higher framerates.