current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 3 down vote favorite
1

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?

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

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.

share|improve this answer
    
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) –  Heisenbug 2 days ago
    
How do I find out how fast my FixedUpdate is? –  Tokamocha 2 days ago
1  
@Tokamocha The rate for fixed update is set in Edit->Project Settings->Time. –  Byte56♦ 2 days ago
    
@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. –  Byte56♦ 2 days ago
    
@Byte56: yes I usually just use the last value. Since now I've never had problems with that, but It's a little bit I'm thinking that averaging would be the most accurate thing to do. Reading this thread, I was just curious if you ever did something similar.. thanks –  Heisenbug 2 days ago
add comment
up vote 2 down vote

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.

share|improve this answer
    
So, if I put everything in FixedUpdate() my game will still register all the inputs, right? –  Tokamocha 2 days ago
    
No, you can put there all game logic update but not input checking. –  NPS 2 days ago
    
oh ok, I get it now, thanks. –  Tokamocha 2 days ago
    
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. –  thr 2 days ago
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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