My game is currently running between 45-60 FPS on iPhone 4, it’s also pretty physics heavy since it’s a racing game with fast moving objects. I have read that forcing the FPS down to 30FPS give you a “smoother” gameplay, which seems to be true in my case from testing I have done in the past.
But, my Fixed Timestep is set at 0.02 (50FPS), so, with the game locked at 30FPS I would assume that it also locks FixedUpdate at 30FPS as well, correct? Will I get a smoother gameplay if I set the Timestep to 0.033? Is there any advantages/disadvantages?
No, FixedUpdate and Update do not run at the same frequency and are not linked. The fixed time step isn’t about how fast your game plays, it’s about a tradeoff between performance and accuracy.
It’s pretty well documented in the Unity reference manual, so I suggest checking that out.
Thanks for the reply! I have read the docs many times but sometimes I like to ask questions when I am not 100% sure, or a little confused. So if I lock my FPS at 30, it only affects Update() and not FixedUpdate(), since the later is controlled by Timestep, correct?
I did do a little test, and I am confused by the results:
FPS locked at 30, Timestep = 0.02, Max Allowed Timestep = 0.035 || In-game FPS is always above 30; eg 30.25FPS
FPS locked at 30, Timestep = 0.033, Max Allowed Timestep = 0.035 || In-game FPS is mostly below 30; eg 28-29FPS
I’m confused because with a Timestep of 0.033, I should have more performance since it reduces accuracy, am I not correct to assume that?!?
If anyone can confirm that this is normal behavior, and if yes, could enlighten me a little if it’s not too much trouble, i would greatly appreciate it. Thanks guys
I’m still trying to wrap my head around this, too. Sorry to bring up an old thread, but I have similar questions.
Although fixed update and update are supposedly independent, they are run in the same thread, right? Isn’t that why there is a Max Allowed Timestep setting?
Suppose your frame time is about 0.03333 on average (30fps) and your fixed time step is 0.033. On average, there should be one physics frame per graphics frame. But sometimes a graphics frame will be faster than average and only be 0.030. So for that frame of graphics, it will be rendering a new image without having updated any physics, so it will look choppy, right?
My game doesn’t use complicated physics and I doubt it would become the bottleneck on performance. I just want to pick an appropriate value to match graphics of 30fps on iPhone.
In ronronmx’s example, it seems to me what may be happening is that in his second setup, the fixed timestep is so close to the target frame rate that sometimes there is just enough time for a second fixedUpdate to happen right before the frame would have been drawn, and so the Update loop is delayed a little bit more.
Timestep settings affect FixedUpdate, which affects all rigid body physics or anything you put into your FixedUpdate loop.
Render frames and physics frames do not have to be synchronised, because rigid bodies can have interpolation (or extrapolation). So physics just ‘occurs’, and at any given point when a render is required, the frame is assembled with whatever state the physics happened to be in at the time.
If your rigid bodies are behaving choppy, ensure they’re using interpolation.
I personally have had great success aiming for 60fps draw speed but only 30fps physics step (0.0333).
One thing to watch out for is, if your fixed step is running at 60 fps and your game is running at an actual 30 fps, then this means for every rendered frame fixed update ran twice.
In most instances this doesn’t matter, but one time I had an instance where I had some processor intensive code in FixedUpdate, and dropping my Application.targetFramerate down to 30 freed up no additional cpu ticks, because it was fixedupdate that was executing heavy code and was doing so at the same rate, regardless of what Application.targetFramerate was running at.
Yeah he’s right, and it goes without saying - don’t calc more often than required. We always shoot for 60fps but if you don’t, even 0.033 might be too often
