Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Feedback [Solved] UI doesn't work with timeScale = 0

Discussion in 'Input System' started by Djayp, Jul 7, 2019.

Thread Status:
Not open for further replies.
  1. Djayp

    Djayp

    Joined:
    Feb 16, 2015
    Posts:
    114
    Trying to do a pause menu, I realized I couldn't... I don't understand why, since UIInputModule uses Time.unscaledTime. Is there any workaround ?
     
    Last edited: Jul 7, 2019
  2. Nixaan

    Nixaan

    Joined:
    May 30, 2013
    Posts:
    118
    I noticed this problem too.

    One workaround I found is to not set (in Project Settings/Input System Package) "Process Events in Fixed Update Only", but instead to select "Process Events In Both Fixed And Dynamic Update".
     
    JaisW, CC_YN, royrochon and 5 others like this.
  3. Djayp

    Djayp

    Joined:
    Feb 16, 2015
    Posts:
    114
    Thank you sooo much ! I wouldn't think it would be so easy :D
     
  4. Adrian

    Adrian

    Joined:
    Apr 5, 2008
    Posts:
    1,061
    Now that the Fixed And Dynamic option is gone, how are we supposed to handle this?

    Our game is physics based, so using Fixed Update to process input seems to make sense. At the same time, we need to set timeScale to 0 to pause physics while in the menu. Setting timeScale to 0 stops FixedUpdate from being called, which I guess is why the input system is no longer updated. However, it seems to be common to pause the game by setting timeScale to 0 and this renders the Fixed Update mode useless.

    I worked around this by switching to Manual Update and updating the input system in FixedUpdate and, if timeScale is 0, also in Update.
     
    DonPuno and Djayp like this.
  5. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    Hey. This is expected, if you update input in fixed updates, and you stop doing fixed updates, you no longer get input. But I guess this is a common enough operation, that maybe we can be better at guiding users about it? Not sure.

    My suggestions would be:
    -switch input to dynamic update while paused
    -consider if you want input in fixed updates at all? You write that "Our game is physics based, so using Fixed Update to process input seems to make sense." - this makes sense for _some_ games (which is why we added the ability to handle input in fixed update, which the old system did not have at all). But I think for most games (even physics based ones), you may not want it:
    1. Even if your game is physics based, your graphics updates are not. For instance if you have mouse look in an fps game, you want to update the camera direction when the screen updates, not when the physics do.
    2. Even if your game is physics based, your users will not be able to respond to things (ie input) faster then you can show things.

    There are exceptions to this, but I think most games are better suited by dynamic updates.
     
    JaisW and Mauri like this.
  6. Nixaan

    Nixaan

    Joined:
    May 30, 2013
    Posts:
    118
    I don't think that's the case. Players don't interpret frames in isolation. We humans track and extrapolate/interpolate gradual movements, we react in advance all the time. Without that skill we won't be able to catch a single thrown ball. Responsive sub-frame controls can definitely be felt by skilled players. In FPS games for example skilled gamers can make difference if the internal update is 32 (if I'm not mistaken they consider it slow), 64 or 128 times per sec.
    Simply put our brain instinctively makes difference where an object should be based on how much time has passed from button press to screen update.

    TLDR: I do not agree. Brain can extrapolate the correct in-between frame timing based on previous frames. And for faster games on slow machines it can easily lead to missing the time window.
     
    Last edited: Aug 24, 2019
    DonPuno and Djayp like this.
  7. Adrian

    Adrian

    Joined:
    Apr 5, 2008
    Posts:
    1,061
    @jonas-echterhoff Thanks for the explanation!

    If Fixed Update mode doesn't make sense in most cases, what are the exceptions, what is the Fixed Update mode intended for?

    It would definitely be good to explain this in the documentation. Right now, it only explains what the modes are, not why you would choose either of them. Also, «if it interacts with Physics, use FixedUpdate()» is a bit of mantra, so I suspect many users will choose Fixed Update mode, maybe without even consulting the documentation.
     
  8. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    Yes, there are situations where Fixed update is likely better, but I don't think there is a clear cut of which games work better in which mode. Examples for game types this has been asked for before, where developers cared a lot about the precise timing of button presses: Pinball games (Flippers), Fighting Games (Combos). I don't think it is a good fit for fps games, because you would usually have the camera rotation not tied to the physics frame rate, and that is one of the primary inputs. But in the end, you should do some (ideally double-blind!) testing to see what works better, or if your players can tell any difference at all (which I think for the majority of game types may not be the case).
     
    JaisW, DonPuno and Adrian like this.
  9. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    Also, if you do such testing, it would be interesting to share the results on this forum, so that other users can profit from the findings!
     
    Last edited: Aug 27, 2019
  10. Kleptine

    Kleptine

    Joined:
    Dec 23, 2013
    Posts:
    274
    As a sample data point, we are building a physics driven game in which you can record and play back inputs. In order to achieve determinism with our playback, input in the FixedUpdate is critical!

    So we appreciate the options! :)

    One thing we've struggled with is that XR HMDs and Controllers seem to forcefully override this behavior. They update OnBeforeRender (it seems their devices are just setup that way). We're ok with a bit of input delay on the hands -- is there any way to get the OculusTouchController's to update on the FixedUpdate as well?

    A side effect of this is also that XR Devices never have the m_CurrentUpdateStepCount set (and wasUpdatedThisFrame is always false). This is due to the fact that only normal update type'd have it set in InputSystem.FlipBuffersForDeviceIfNecessary. :(
     
  11. jeffweber

    jeffweber

    Joined:
    Dec 17, 2009
    Posts:
    616
    I would like to change my InputSettings update mode to dynamic when game is paused and back to fixed when not paused.
    How do I change the update mode with code at runtime?

    -Jeff
     
    DonPuno likes this.
  12. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,952
Thread Status:
Not open for further replies.