10
\$\begingroup\$

I was told to use Update() for graphics and FixedUpdate() for physics, but sometimes my inputs won't register when I use FixedUpdate(). It works fine if I use Update() for everything though.

Should I bother with FixedUpdate(), or am I doing something wrong?

\$\endgroup\$
10
\$\begingroup\$

FixedUpdate can run faster or slower than Update depending on your settings. That'll depend on load (how fast Update is running) and speed you have set for FixedUpdate (found in Edit->Project Settings->Time). Ideally, since Update is run once per frame, this is where you want to capture input. If you need to act on input in the FixedUpdate method (like controlling physics bodies), set flags in Update then handle them in FixedUpdate:

bool leftMouseDown = false;

void Update()
{
    if(Input.GetMouseButtonDown(0))
        leftMouseDown = true;
}

void FixedUpdate()
{
    if(leftMouseDown )
    {
        //update physics bodies with input
        leftMouseDown = false;
    }
}

It's still a good idea to control physics from the FixedUpdate method, since it's unlikely the physics needs to be updated as often, and physics on a fixed update is much easier to predict (determinism) than physics on a variable update.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ what about if instead of a bool condition (es.GetMouseButtonDown) we need to read value from an axis (Input.GetAxis("Horizontal"))? If update is executed more times then FixedUpdate, what's your advice in that case? Should we eventually consider to calculate the mean value of the axis occured during the several Update before consuming it into Update? (+1 btw) \$\endgroup\$ – Heisenbug Apr 20 '14 at 20:42
  • \$\begingroup\$ How do I find out how fast my FixedUpdate is? \$\endgroup\$ – Tokamocha Apr 20 '14 at 21:01
  • 1
    \$\begingroup\$ @Tokamocha The rate for fixed update is set in Edit->Project Settings->Time. \$\endgroup\$ – MichaelHouse Apr 20 '14 at 21:09
  • \$\begingroup\$ @Heisenbug Personally I would just use the last value and see how well that works. If I get unexpected results, I might calculate a running average of the axis value until it's processed by FixedUpdate. That's one of those things that needs some play testing to really figure out what "feels" right. \$\endgroup\$ – MichaelHouse Apr 20 '14 at 21:11
  • 1
    \$\begingroup\$ I've found in recent tests that, contrary to what's implied in the docs, fresh input flags are available already in FixedUpdate (on PC at least). So setting a flag in Update and then acting on it in the next FixedUpdate after that (ie. the next frame) as shown here can actually add a frame of latency to the game, relative to handling the input in FixedUpdate directly. This does require some care though to avoid double-handling input on frames with multiple FixedUpdates, or missing inputs on frames with no FixedUpdate. \$\endgroup\$ – DMGregory Sep 12 '17 at 2:44
7
\$\begingroup\$

You need to understand what each one does. Update() gets called as often as possible (not sure, maybe it can be capped), either way - each frame. FixedUpdate() gets called every constant amount of time (hence "fixed").

Input goes into Update(), as simple as that (because as you noticed FixedUpdate() might not catch the input event). Game logic however might go into either one. Physics needs to be deterministic and that's why it should be in FixedUpdate(). Other things don't have to. Depending on the usage you have to decide which function is appropriate.

Althouth it's worth to say that some applications have all game logic update in FixedUpdate() (even outside of Unity) - it's called "fixed step game loop". Having all update code in a fixed step function gives you determinism and makes your app more likely to behave the same way each time (and on each device). Also allows for some fancy features, like replays.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ So, if I put everything in FixedUpdate() my game will still register all the inputs, right? \$\endgroup\$ – Tokamocha Apr 20 '14 at 21:08
  • 1
    \$\begingroup\$ No, you can put there all game logic update but not input checking. \$\endgroup\$ – NPS Apr 20 '14 at 21:37
  • 2
    \$\begingroup\$ this answer is full of miss-information. First of all FixedUpdate gets called 1/fixedDeltaTime times per second, not every n:th fixedDeltaTime. Second, game logic should always go in FixedUpdate as it makes it easier o reason about. Update is for rendering purposes only (I know almost no one in the Unity community follows this, but that's really how its supposed to be done). Third, FixedUpdate and its relationship with the physics engine has nothing to do with determinism. \$\endgroup\$ – thr Apr 21 '14 at 5:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.