koobas.hobune.stream
Timings completely different on different computers
Can someone help me with this? I have a feeling its a simple idea, but... I just can't get it...
The thing is, I'm using two computers. And on both of them, there are quite a few differences based on Update...
Enemies move faster on the faster computer, attacks trigger earlier on the faster computer, etc etc...
I think it has to do with relying on FrameRate, but I'm not too sure about how to change my FrameRate-dependant code to a more reliable, global code...
Thanks!
because it's the second page of the scripting manual. http://unity3d.com/support/documentation/ScriptReference/index.html
That's the first page ;) ... you want http://unity3d.com/support/documentation/ScriptReference/index.$$anonymous$$eeping_Track_of_Time.html
The page that you linked is what I'd call the second page, and what I was referring to. You can't tell what page it is if you don't see the pages listed. (I'd call my link the table of contents.) You're probably right that this person needed the direct link, though, however, I have my doubts that they'll read it, or Eric's answer. Seems a lot of typing when the info is easy to get to; I don't understand this at all... 8-/
True, but that second page is awfully sketchy on details -- it says what to do, but very light on explaining why.
As Eric5h5 says, you can use Time.deltaTime. So if (for example) you are moving something a distance of x per frame, instead move it x * Time.deltaTime -- now you are moving distance x per second, instead of x per frame (yes, you'll want to make x bigger). Since seconds are constant (barring serious gravitational disturbances or relativistic effects) and frames are not, you will now get constant velocity.
The other option is to make your updates in FixedUpdate instead of Update -- FixedUpdate is called a fixed (surprise!) number of times per second, so if you move distance x, you'll be moving k * x per second, where k is the fixed update rate (typically 60, but can be configured).
Note that if your frame rate is low, then FixedUpdate is inefficient -- you're moving an object more often than you're displaying it, which is pointless. Better to move once per display refresh (i.e. in Update) instead, and use deltaTime appropriately.
The exception is for operations like integration of physics calculations which are sensitive to the timesteps involved. Like Jessy says, read the manual ... ;)
FixedUpdate isn't necessarily fixed, either...depends on the framerate and what you have maximum allowed timestep set to. Plus you can get jittery-looking movement since FixedUpdate doesn't usually match the framerate. Basically you really shouldn't use FixedUpdate as a substitute for proper framerate-independence; just use Update or coroutines and Time.deltaTime.
Thanks for the help! Your answer was very helpful. And damn, didn't notice the Time section, argh...
Use Time.deltaTime where appropriate. If you just have things happen every frame without regarding the time difference from the last frame, then naturally the timings will differ as the framerate varies.
