Fixed or variable frame rate for modern games?

Community Community & Industry Discussion
1

TLDR: A fixed frame rate fixes all of my physics problems, but is a fixed frame rate game viable nowadays, or are there compelling reasons to ship with a variable frame rate?

I am making a physics-heavy game that simply breaks when I run it with the default variable frame rate. In this example, I am calculating the stopping distance of a moving object, and then indicating the stopping point with the arrow.

I tried substepping, but unfortunately it did not fix the issue. Frame smoothing did not work either.

However, when I set a fixed frame rate, it runs beautifully…the physics all just work…regardless of how high or low I fix the frame rate. (any slight stutter here is just the gif)

So…

Is fixed frame rate viable for a production game nowadays?

What happens if I set the rate too high and the player’s machine can’t run it?

Is running a fixed frame rate viable for a multiplayer game? (I have not tried this yet but want to in the future)

I tried setting the frame rate at 200, and the game simply ran at my max frame rate of 165. So is there no consequence to setting the rate too high and just letting it run at whatever the machine can run it at?

I read that fixed rates are not ideal for games because it could potentially prevent players from utilizing all of their graphical hardware capability, and therefore the game would not be taken seriously. Any thoughts on that?

Any other consequences I’m not thinking of?

Thanks in advance!

1 Like
2

I am, pretty strongly, in “camp fixed frame rate.”

Given the way high-end gaming monitors are going, though, you’re going to want to do one of two things to avoid the game just rendering 3 frames of each world state until the next simulation tick …

  1. Run physics at 60 Hz, and then render inter- or extrapolated physics entities for tween frames
  2. Run physics much faster – 240 Hz might be “the new 60 Hz.” This also has the benefit that tunneling is reduced, and each object moves less so collision queries are cheaper.

Option 1) is annoying because it either means you render objects that slightly tunnel when they hit other objects, or it means you’re always rendering everything up to one frame behind.

Option 2) is pretty nice, with the caveat that, although simulating 1 second at 240 Hz, isn’t 4x more expensive than at 60 Hz (because of frame coherence benefits,) it still is noticeably more time – say, 2-3x as costly. That being said, CPUs are faster now, and have more cores now, and we can’t let the graphics people have all the fun – 240 Hz fixed-frame physics is where I believe the current sweet spot might reside. (Or 360 Hz, if you want slightly nicer interactions with 160/180 Hz panels.)

On lower-end machines, like Intel Integrated that run at 15 Hz and uses the memory bandwidth for graphics as well as compute, you might even have a mode where you combine frames and run a single bigger step, that’s an integral number of individual steps but that would be… harder, and bring back some of the draw-backs of variable step time.

3 Likes
3

try settings the fixed frame rate to something high like 500 and see what happens lol.
the same thing will happen if someone’s machine doesn’t have the power to render 120 frames if u have set to to render 120.

last time I used fixed frame rate for my game everyone emailed me about why the game runs so slow despite having a high frame rate.

1 Like
4

jwatte what do you think about the solution described in this article? Would that allow for Option 2, while still enabling bigger steps for low end machines?

https://avilapa.github.io/post/framerate-independent-physics-in-ue4/

5

Substepping has been an option for a long time, but it unfortunately doesn’t guarantee fixed time steps – some fractional step may/will also be stepped between each rendered frame.

6

Sorry to say but a physics heavy game made in unreal is just nonsense.

Do you want your game to work? Yes?
Implement a real physics SDK.

Otherwise, sure. Unreal’s take on a broken physx implementation, or Chaos builds are ok.
But your game won’t really be “heavy on physics” it’ll be mostly just smoke and mirrors that makes it look like physics are Good. With some core limitations on stuff like cloth.

There’s plenty of reasons top AAA games that use unreal use other things to get physics going (mostly Havok I would guess?)

As far as frame limiting goes.
It would definitely depend on target hardware, not really on “it fixes all physics issues”.

What will the game be released on? And of those, what is the worse performing item?
Based on that, what frame rate does It support?

Btw, all that frame limiting does is bloat the rendering thread to allow for a max number of frames.
Meaning that there’s a very real possibility to drop well below the limit and get problems either way.

And all that said.

First.
If you did the same thing in c++ it may work better.

Second.
You have to see when that tick function used to position the arrow is acrually firing.
What’s that mean? Well in BP you have tick groups.
Read this.

Try Pre Physics. Or any other groups to see if any of them make a difference for the same code first.

Third.
Your issue really has nothing to do with physics really.
This is just plain math and error margin based on the value of delta time.
It is also additionally limited by Float instead of a double for extra precision.

Fourth.
Where is the calculation happening, and why every tick?
It should really only happen once the acceleration is 0, once.
To do it that way, you can’t half-■■■ the math, you have to take the exact calculation the engine is doing for whatever movement thing its using - and then it will always be identical.
You can refer to the distance matching locomotion topic in the animation section of the forum for some code bits and physics tips on how that matches the movement component.
Have yet to see anything in the same direction for peojectiles…

1 Like
7

Omg you’re right, it was the tick group.

I set the actor to tick on Post Physics and turned off fixed frame rate. It works.

I wasn’t aware of the tick functionality, and spent so much time trying to resolve prior to posting this. Thank you MostHost_LA!

1 Like
8

Does UE5 not allow for Async physics tick with Chaos?