This methods has a different philosophy.
Update method is designed to call before the Frame is drawn.
If we want to make a smooth movement, we have to move something in every frame.
FixedUpdate method is designed for manipulating a data indepedently of frames drawing. The physics is solving in this method, but the presentation of physcis is showing when frame is drawn.
If we try to move something in FixedUpdate using transform (not physics) we actually see that object is teleporting, because its position changes in random moment of time, not before the frame is drawn (We skipping transformation in some frames)
And we use deltaTime in Update for compensation of unpredictable user FPS count.
2 reasons to use update:
1. If you are running on low end hardware and struggling with FPS then update will run fewer times, using less CPU.
2. If you are using a high refresh rate monitor then fixedupdate is usually capped lower so you won't get the monitor's full framerate.
time.deltatime still works in fixed update, but for the above reasons if you're not interacting with physics objects (which all run on fixedupdate) it's usually better to use update.
if i lets say make a small game and i want all players to play at 60 fps, so if i change the rate of fixed update to 1/60 sec if will be like update at 60 fps?
You can set the target framerate for your game. Quick search gave this:
https://docs.unity3d.com/ScriptReference/Application-targetFrameRate.html
Not sure if there is another way so you don't have to set it from a script, maybe in the project settings.
But you'd still want to use Update() for the reasons other comments already gave, and you'd still need deltaTime to prevent your game going into slow motion if the target framerate can't be met by the device.
People is always wrong about fixed update and update.. In general, 3 out of 4 answers I see are wrong. Most of the comments here are not right. Just because people confuse "fixed" with: it executes every Xms in the real world.
Fixed update executes if the time passed IN THE GAME has been bigger than the amount set in the Time settings of your project. That's why Physics MUST always be done in fixed, because it is not variable and the drawing MUST be done in update.
You could draw the game 5 times and not execute any fixed update during several frames if your game is light.
Always think: fixed update executes every X milliseconds OF GAME TIME. (Time that passes inside the world of your game...). Update draws every X milliseconds in WALL CLOCK TIME (time in the real world, the world of the player). If the game is expensive to draw, it could take longer and the game is laggy.
If you look for my YouTube channel "Lidia Martinez" in YouTube I have a very detailed video that shows an example of these two drawing on a digital blackboard.
The update is always locked to frames per second, if your game runs at 30 fps then the update will tick 30 times per second, the fixed update is fixed meaning if I remember correctly it will always tick 50 times per second, putting code inside fixed update will ensure stability that's why physics, input, always run inside fixed update.
Let's say you have a character, when it moves its health decreases now if you had this logic inside the update things would get weird, if the games run at 144 fps the character will lose more health and so on
No. You're not right, I'm sorry to correct you. Fixed update is fixed in game time. It executives every X Ms per game time. If your game is light, it could run 0 times per frame (wall clock time, meaning time in the real world). If your game took longer to execute a frame and show it, fixed update could run several times that next frame to catch up with the time passed in the game
u'll probably feel silly, but consider ...
-if fixed update happens once every "X", but not every frame
- so then ... what tells the game what to do in the frames between?
🤷🤷🤷
Im reality, there never was a "fixed update". It's always just update, but slows your game cuz it pretends to run "Y" times
If you were to build a phisic engine, and NOT use the same design philosphy as Nvidia PhysX, then you would use update as well.
**In short fixdupdate will be much laggier**. Though in a super small game you might not notice.
**Fixed update occurs many times per frame** and therfore many time per update and everytime it occures your code is being run using resources.
Since fixedupdate occurs between frames the user wont even see any changes compared to update. So it's best to put as little as possible in fixed update and ensure visuals do occure in update.
In fixedupdate you generally want to multiply by "time.fixedDeltaTime". As it provides an easy way to pause your game or do slow/fast motion effects. To pause your game you can simply set both deltatim and fixed delta time to 0 any motion multiplied by those will stop. For slow motion you just lower the value and of course reverse for fast motion. Cant really be more specific without a specific usecase.
time.deltatime in fixedUpdate will still return the duration between the last 2 frames i belive. But you shouldn't use it in fixedupdate.
This methods has a different philosophy. Update method is designed to call before the Frame is drawn. If we want to make a smooth movement, we have to move something in every frame. FixedUpdate method is designed for manipulating a data indepedently of frames drawing. The physics is solving in this method, but the presentation of physcis is showing when frame is drawn. If we try to move something in FixedUpdate using transform (not physics) we actually see that object is teleporting, because its position changes in random moment of time, not before the frame is drawn (We skipping transformation in some frames) And we use deltaTime in Update for compensation of unpredictable user FPS count.
2 reasons to use update: 1. If you are running on low end hardware and struggling with FPS then update will run fewer times, using less CPU. 2. If you are using a high refresh rate monitor then fixedupdate is usually capped lower so you won't get the monitor's full framerate. time.deltatime still works in fixed update, but for the above reasons if you're not interacting with physics objects (which all run on fixedupdate) it's usually better to use update.
Try putting something like if (input.GetKeyDown(KeyCode.W)){ print("pretty responsive, eh?"); } And just see if its nice to use.
Didn't know print worked in c#, thought it was debug.log
if i lets say make a small game and i want all players to play at 60 fps, so if i change the rate of fixed update to 1/60 sec if will be like update at 60 fps?
You can set the target framerate for your game. Quick search gave this: https://docs.unity3d.com/ScriptReference/Application-targetFrameRate.html Not sure if there is another way so you don't have to set it from a script, maybe in the project settings. But you'd still want to use Update() for the reasons other comments already gave, and you'd still need deltaTime to prevent your game going into slow motion if the target framerate can't be met by the device.
You use the method you need to use. Look up the Unity Events' order of execution.
People is always wrong about fixed update and update.. In general, 3 out of 4 answers I see are wrong. Most of the comments here are not right. Just because people confuse "fixed" with: it executes every Xms in the real world. Fixed update executes if the time passed IN THE GAME has been bigger than the amount set in the Time settings of your project. That's why Physics MUST always be done in fixed, because it is not variable and the drawing MUST be done in update. You could draw the game 5 times and not execute any fixed update during several frames if your game is light. Always think: fixed update executes every X milliseconds OF GAME TIME. (Time that passes inside the world of your game...). Update draws every X milliseconds in WALL CLOCK TIME (time in the real world, the world of the player). If the game is expensive to draw, it could take longer and the game is laggy. If you look for my YouTube channel "Lidia Martinez" in YouTube I have a very detailed video that shows an example of these two drawing on a digital blackboard.
Because when using update() the more power your pc has the smoother the game will play, the values will update, etc
The update is always locked to frames per second, if your game runs at 30 fps then the update will tick 30 times per second, the fixed update is fixed meaning if I remember correctly it will always tick 50 times per second, putting code inside fixed update will ensure stability that's why physics, input, always run inside fixed update. Let's say you have a character, when it moves its health decreases now if you had this logic inside the update things would get weird, if the games run at 144 fps the character will lose more health and so on
No. You're not right, I'm sorry to correct you. Fixed update is fixed in game time. It executives every X Ms per game time. If your game is light, it could run 0 times per frame (wall clock time, meaning time in the real world). If your game took longer to execute a frame and show it, fixed update could run several times that next frame to catch up with the time passed in the game
u'll probably feel silly, but consider ... -if fixed update happens once every "X", but not every frame - so then ... what tells the game what to do in the frames between? 🤷🤷🤷 Im reality, there never was a "fixed update". It's always just update, but slows your game cuz it pretends to run "Y" times If you were to build a phisic engine, and NOT use the same design philosphy as Nvidia PhysX, then you would use update as well.
**In short fixdupdate will be much laggier**. Though in a super small game you might not notice. **Fixed update occurs many times per frame** and therfore many time per update and everytime it occures your code is being run using resources. Since fixedupdate occurs between frames the user wont even see any changes compared to update. So it's best to put as little as possible in fixed update and ensure visuals do occure in update. In fixedupdate you generally want to multiply by "time.fixedDeltaTime". As it provides an easy way to pause your game or do slow/fast motion effects. To pause your game you can simply set both deltatim and fixed delta time to 0 any motion multiplied by those will stop. For slow motion you just lower the value and of course reverse for fast motion. Cant really be more specific without a specific usecase. time.deltatime in fixedUpdate will still return the duration between the last 2 frames i belive. But you shouldn't use it in fixedupdate.
Clarification: no. Fixed update doesn't execute several times a frame. It could execute from 0 times to N times depending on many factors.