I mean for games with no performance issues, of course.
What monitor has a refresh rate exactly as fast as you want to run physics?
1 Like
And more importantly: Why would you want to miss input and missinterpret it just cause you don’t check it as often as it happens (unity samples the input at a rate thats equal to update)
In some cases, fixedupdate will be running faster than your main loop (ios for example).
not needfully, only if you set it up badly.
But the important part is that it will run in a stable frequency, a thing update will not offer on mobile in 99% of the cases
It’s nothing to do with setting it up badly. I need physics to run at a very specific rate regardless of actual framerate. The sound is also tied into fixedupdate, and its essential that physics and sound go off on cue in my music app.
This runs at 60fps internally, while the actual update loop runs at 25-30fps. There’s no other reliable way of doing it.
Regardless of the necessity, that sounds like a bad setup to me! 
it’s not bad, you’ll love it.
The problem is, physx has to run 60hz in order to keep the notes in time with the physics else it sounds “off” 
its a really unique music app so I’m hoping you have a spare ipad so I can throw a free itunes coupon at you to have a go on (I know you like music stuff!)
For games which don’t require that degree of fidelity, I would probably have fixedupdate run as low as 20hz. 30 tops!
It’s worth noting that my scripts are only taking up 12ms anyways, so its the graphics that hold it back.
What I wonder is why won’t you stick to Update and use Time.deltaTime… Everytime I use FixedUpdate something works funny! Take input, for example: do I need an Update for input and a FixedUpdate for physics?! That slows down my current game on an iPod to a crawl! 8(
FixedUpdate by default is 50fps and ideally you’d be getting 60fps, so not really. Aside from the fact that FixedUpdate runs at whatever rate you tell it to, and sometimes it’s a good idea to lower it as much as possible, so I’d say it’s not uncommon that the framerate (if that’s what you mean by main loop) is faster than FixedUpdate.
Because it’s only for physics. You can’t put input in FixedUpdate (because you might miss events), you can’t put game logic in FixedUpdate (because you might change FixedDeltaTime and that would screw all your timing). Also you can’t count 100% on FixedUpdate actually running at the requested interval, depending on framerate and what you have maximumDeltaTime set to.
–Eric
1 Like
Note, I am only talking about games with no performance issues so leave this aspect aside, please. Why I don’t want to use deltaTime? Because I want the same game-mechanics, whenever you play it, whereever you play it. That is a point that seemingly most people don’t even understand, but it is my preference. If I make a rule-set, I want to keep it exactly the same, always. It is also better qualified for competitive gaming.
@Jessy
Use interpolation to maintain silky-smooth picture.
@dreamora and input
A game without performance issues should run at least with 60-120 hz. It is fast enough to practically not miss a frame. Even in variable step you miss most of the input-states, if you want it that way. Nearly the whole period between refresh-cycles don’t matter, the input is only picked once in this intervall. What matters is only that you have your input ready for the upcoming frame. And if you call fixedUpdate at that high-rates it doesn’t matter that much if the same input is executed 2 times or 0 times in a row in the worst case since it is only a tiny fraction of a time. Or did you have bad experience with it? Do you notice issues with mouse-movement, as example? Like I said, my condition is that the game is running at 60-120hz, not slower.
Doesn’t Update() get capped by rendering speeds though? I thought it did, which is why I am assuming my Update() is running around 30 (as it is 30fps) and my physics around 60.
Update runs as fast as the screen-refresh, but only if vsync is on, otherwise it updates as fast as it can (you can turn it off to make your game more responsive). If you run physics at 60fps then it simply calls fixedUpdate 2 times in a row after update in the same game-loop. Thats the only way to do it since it is not multithreaded. That is why the same input can be processed for 2 fixedUpdates, but given that rate, especially for games based on digital-button input it shouldn’t practically matter. No one will hit a button for less than a frame(virtua-fighter uber hardcores may be), so it would also register even when one fixedUpdate-frame is left out (emty game-loop).
Yeah, I am not referring to smartphones first place. Not sure you feel a problem there. I can only imagine an issue with gesture-controls, something based on a drawn-path, but there is certainly no problem with digital input styles. You simply won’t tap at that high rates.
Update is processed once per frame.
Also, setting physics to 60 on mobile does not exactly sound like a stunning idea, the game must be relatively easy on the cpu otherwise to get through with that. I would opt for 30 on mobile cause thats the FPS you will end on in a game that reasonably uses physics anyway (as you can only be on 60, 30, 20, 15, … stable due to the vsync at 60). Also you want to ensure a low cpu load if you don’t need a high one so the cpu can gate and disable sections unneeded or underclock to save battery
You can turn off vsync to make the game more responsive since update will update as fast as possible (not waiting for a screen-refresh to be in sync with it). The only disadvantage you might get is screen-tearing. Choose your deal.
Yes but setting physics to 30, 40 or even 50 fps means that the sound isn’t exactly regular when the ball strikes the surface, because there isn’t enough fidelity in the physics.
setting them to continous didn’t fix the issue at all, but setting the fixedupdate higher did fix the issue of sounds not being completely regular (ie the movement step wasn’t a high enough granularity).
imagine a ball bouncing really, really fast between two opposing walls that are close together. You would need a high fixedupdate to ensure the physics were relatively stable and not sinking too deep into either wall to throw off the timing.
I am just saying that if you want higere update-rates, then vsync can be turned off. Your physics rate shall stay the same.
I need to elaborate. I am not sure you are aware about it but this attitude alone is enough reason for me to avoid Unity altogether. Why the hell is it only for physics? If you would put Input in FixedUpdate you would not miss anything. For me physics is everything that moves and interacts with the environment, pretty much the most of the game.
Don’t you see that a setted rule-set should stay the same, if possible? Don’t you care about competitive game-mechanics?
How can I screw up timing if everything is in FixedUpdate? What are you talking about?
And I don’t request to run fixedUpdate at the same intervall regarding one or two frames as you seem to make a deal about it. I request it to be the same over a period, which it does. I know all the technicalities behind the game-loops and their purpose.
So really, what is the matter? The only reason to avoid it is a stuttering picture. It seems you don’t have a solution for visual interpolation for everything that moves, only for stuff that is processed by physics. Is that correct?
Sorry but no one can take how disappointed I am. No matter what engine I am looking at, it seems no one is able to bring up a deeper technical insight and a quality-perspective, from a competitives player point of view. It is something fundamental.
I looked at XNA and also there, they cannot even make the fixed Timestep right. Their implementation is just numerically unstable and always less in sync. Luckily the framework is flexible enough so I rolled my own solution which I am really satisfied with.
But with an engine I can’t so I am searching for ways how to keep a smooth picture AND maintaing consistent game-mechanics. Really, is that difficult to understand?
It’s not only for physics. Those guys are delivering an opinion based on their experiences. They aren’t representative of what unity is saying. I respect them, certainly, but I don’t have to agree with them.
For example, fixedupdate is also used by the sound engine by default (although it can be toggled to use Update instead).