6 ms·

The mixing of unfixed and fixed timesteps leads in my opinion to one of the greatest headaches in game development. Unity and Godot for that matter advice you t

The mixing of unfixed and fixed timesteps leads in my opinion to one of the greatest headaches in game development. Unity and Godot for that matter advice you to put all physic related scripts in a FixedUpdate method and game Logic scripts inside Update. But it is never that simple. So you have to process your input in Update and forward actions to FixedUpdate yourself if physic objects are affected. And this alone leads to numerous tricky problems. And then everything goes down quickly if you have physic related objects which also affect your gamelogic. What to do? Process everything in FixedUpdate always? Well, say goodbye to immediately processed input. Additionaly, don't forget that you need to interpolate or extrapolate rigidbodies, otherwise you won't see them move smoothly if the physic world updates at 60HZ and your screen at 144Hz. And as soon as you do that, the representation on the screen does not always match the physic world, which is really bad for fast gameplay. And if you do something wrong, your whole physic simulation can explode. I haven't found a nice and simple solution to all of this, which works for all cases, even though I really tried [1] and I believe many games suffer from delayed input handling, micro-stuttering or unreliable physics due to mixing fixed and unfixed timesteps. [1] https://www.zubspace.com/blog/smooth-movement-in-unity https://www.zubspace.com/blog/smooth-movement-in-unity

badsectoracula 6y ago
Not using a fixed update rate is why i have to run a framecapping software on my fast PC in pretty much every game that is older than a few years. Do not bother, Carmack couldn't get it right, Sweeney couldn't get it right, the guys at Monolith couldn't get it right, pretty much nobody could get it right. Even if you think your code works, it wont work. Floating point doesn't like operations like "thing += delta * speed", especially when delta varies from frame to frame. Use a fixed time step for all updates (not just physics updates), use a high update rate like 60Hz to avoid any perceptible delays, interpolate the visible state in intermediate frames and if your game really needs immediate response (in practice this is only visible with mouse look in high refresh rate screens - other forms of input are not perceptible), do the visual change on the input event (e.g. rotate the camera when you move the mouse, play the sound effect when you hit fire or whatever) but let the game logic still run at the fixed update rate. Consider anything else and you will have a broken game.
tgb 6y ago
Why do they recommend game logic in the non-fixed update?
- zubspace 6y ago
  Update is bound to the framerate. And if you have a faster PC or a higher refresh rate you can perform more logic. So why limit yourself by a fixed timestep? But well, nothing prevents you from doing game logic in FixedUpdate and maybe it could even be beneficial. For example, you don't want your AI to run each frame. But in my opinion Update should still be the place most of your logic resides. Even in the case where you don't want logic to run each frame, simply keep track of the time passed and run your logic in self defined intervals from inside Update. Update is the place you handle your input and you can affect the next displayed frame immediately. The last part is really important, because you don't want the player to wait for the next physic step after he pressed a button (but unfortunately many games do). I think a large part of this problem comes from the fact, that the Update/FixedUpdate logic of most game engines is very static. In many cases you can't really influence its behavior. Unity allows you to invoke the FixedUpdate cycle manually from inside Update, but it can lead to other problems.
  - BoorishBears 6y ago
    This is completely wrong. FixedUpdate can be called several times in one frame or not at all because it's designed to run a consistent amount of time regardless of framerate. Don't put game logic that involves collecting input in FixedUpdate or you will miss inputs and get all types of errant behavior, definitely don't put AI in there... - The rule of thumb: FixedUpdate is for per-unit-time, like X meters per second, Update is for per-frame. (really that boils down to, FixedUpdate is for physics. If you want FixedUpdate for something that isn't physics in Unity, use a Coroutine/InvokeRepeating) Things in Update will happen less often on a slow computer and more often on a fast one, you don't want your physics to behave differently on a slow computer
    - cosarara 6y ago
      Aren't inputs usually on a queue? So you shouldn't miss them. And why shouldn't AI move at the same time as the physics? You don't want your AI to behave differently on a slow or a fast computer.
ajross 6y ago
> The mixing of unfixed and fixed timesteps leads in my opinion to one of the greatest headaches in game development Here's the scarier truth: bugs due to timestep handling like this are really just evidence that you're hitting the stiffness edge of the underlying differential equation. And you can't fix that with timestep, really, at all. At least not with feasible performance. You have to move to fancier solver algorithms if you want any hope of controlling these things in this regime. And even then the yet-scarier truth is that you'll never be able to control it even there, but at least you'll have hope of recognizing and understanding it. Source: wrote a physics engine for FlightGear many years ago, based on a solid, simple RK4 engine, thought I understood everything perfectly and had picked all the right algorithms. And holy tuning hell, Batman... did you know how stiff landing gear are when you're just sitting motionless on the ground? Integration algorithms, in practice, are easily the most frustratingly intractable area of numerics programming. And yet they come up in situations like this where they seem "obvious". It's a giant trap.
- neutronicus 6y ago
  People like RK4 for arbitrary ODEs because it's fast and usually-good-enough but it is emphatically not what you want for simulating Hamiltonian systems (the two-body problem for example has no bounded elliptical orbits when integrated with RK4; everything escapes eventually). Usually what you want is some sort of simple lower-order symplectic scheme like Leapfrog. If however that is not feasible for efficiency reasons volume-preserving is often sufficient (again this produces noticeable errors in solutions of the two-body problem in the form of orbit precession, but it gets boundedness of orbits right at least)
  - ajross 6y ago
    Yeah, I haven't touched this world for over a decade, don't read those papers, had to look up "sympletic" to be sure I was remembering the right thing... and I am still like 80% sure you're full of it. There are no easy solutions in this space. The routine physics of the real world that the game developers in the linked article are struggling with are simply not susceptible to error free integration, period. The fact that you're talking about orbits and 1/r potential fields tells me you haven't really groked this. The example above wasn't a joke: you can get the two body problem nailed down perfectly and your code will still fall over when a character stubs their toe or bounces off a wall.
klodolph 6y ago
Something that’s surprisingly tricky to get working well in Unity is to have the player hold an item in first-person perspective and still make that item a physics object. The camera will update at one rate and the physics objects will update at another. It’s easy to end up with an object that jitters horribly as you move it around.
DavidVoid 6y ago
On a related note, Blizzard added a feature to Overwatch about half a year ago that enables the processing of mouse input at 1000Hz! Or well, it doesn't process it at that rate, but it figures out where you were aiming when you fired, even if you fired right between two ticks (or frames). The videos in their blog post [1] explain it much better than I can. [1] https://us.forums.blizzard.com/en/overwatch/t/new-feature-high-precision-mouse-input-gameplay-option/422094 https://us.forums.blizzard.com/en/overwatch/t/new-feature-hi...

badsectoracula 6y ago

Not using a fixed update rate is why i have to run a framecapping software on my fast PC in pretty much every game that is older than a few years. Do not bother, Carmack couldn't get it right, Sweeney couldn't get it right, the guys at Monolith couldn't get it right, pretty much nobody could get it right. Even if you think your code works, it wont work. Floating point doesn't like operations like "thing += delta * speed", especially when delta varies from frame to frame. Use a fixed time step for all updates (not just physics updates), use a high update rate like 60Hz to avoid any perceptible delays, interpolate the visible state in intermediate frames and if your game really needs immediate response (in practice this is only visible with mouse look in high refresh rate screens - other forms of input are not perceptible), do the visual change on the input event (e.g. rotate the camera when you move the mouse, play the sound effect when you hit fire or whatever) but let the game logic still run at the fixed update rate. Consider anything else and you will have a broken game.

tgb 6y ago

Why do they recommend game logic in the non-fixed update?

zubspace 6y ago
Update is bound to the framerate. And if you have a faster PC or a higher refresh rate you can perform more logic. So why limit yourself by a fixed timestep? But well, nothing prevents you from doing game logic in FixedUpdate and maybe it could even be beneficial. For example, you don't want your AI to run each frame. But in my opinion Update should still be the place most of your logic resides. Even in the case where you don't want logic to run each frame, simply keep track of the time passed and run your logic in self defined intervals from inside Update. Update is the place you handle your input and you can affect the next displayed frame immediately. The last part is really important, because you don't want the player to wait for the next physic step after he pressed a button (but unfortunately many games do). I think a large part of this problem comes from the fact, that the Update/FixedUpdate logic of most game engines is very static. In many cases you can't really influence its behavior. Unity allows you to invoke the FixedUpdate cycle manually from inside Update, but it can lead to other problems.
- BoorishBears 6y ago
  This is completely wrong. FixedUpdate can be called several times in one frame or not at all because it's designed to run a consistent amount of time regardless of framerate. Don't put game logic that involves collecting input in FixedUpdate or you will miss inputs and get all types of errant behavior, definitely don't put AI in there... - The rule of thumb: FixedUpdate is for per-unit-time, like X meters per second, Update is for per-frame. (really that boils down to, FixedUpdate is for physics. If you want FixedUpdate for something that isn't physics in Unity, use a Coroutine/InvokeRepeating) Things in Update will happen less often on a slow computer and more often on a fast one, you don't want your physics to behave differently on a slow computer
  - cosarara 6y ago
    Aren't inputs usually on a queue? So you shouldn't miss them. And why shouldn't AI move at the same time as the physics? You don't want your AI to behave differently on a slow or a fast computer.

ajross 6y ago

> The mixing of unfixed and fixed timesteps leads in my opinion to one of the greatest headaches in game development Here's the scarier truth: bugs due to timestep handling like this are really just evidence that you're hitting the stiffness edge of the underlying differential equation. And you can't fix that with timestep, really, at all. At least not with feasible performance. You have to move to fancier solver algorithms if you want any hope of controlling these things in this regime. And even then the yet-scarier truth is that you'll never be able to control it even there, but at least you'll have hope of recognizing and understanding it. Source: wrote a physics engine for FlightGear many years ago, based on a solid, simple RK4 engine, thought I understood everything perfectly and had picked all the right algorithms. And holy tuning hell, Batman... did you know how stiff landing gear are when you're just sitting motionless on the ground? Integration algorithms, in practice, are easily the most frustratingly intractable area of numerics programming. And yet they come up in situations like this where they seem "obvious". It's a giant trap.

neutronicus 6y ago
People like RK4 for arbitrary ODEs because it's fast and usually-good-enough but it is emphatically not what you want for simulating Hamiltonian systems (the two-body problem for example has no bounded elliptical orbits when integrated with RK4; everything escapes eventually). Usually what you want is some sort of simple lower-order symplectic scheme like Leapfrog. If however that is not feasible for efficiency reasons volume-preserving is often sufficient (again this produces noticeable errors in solutions of the two-body problem in the form of orbit precession, but it gets boundedness of orbits right at least)
- ajross 6y ago
  Yeah, I haven't touched this world for over a decade, don't read those papers, had to look up "sympletic" to be sure I was remembering the right thing... and I am still like 80% sure you're full of it. There are no easy solutions in this space. The routine physics of the real world that the game developers in the linked article are struggling with are simply not susceptible to error free integration, period. The fact that you're talking about orbits and 1/r potential fields tells me you haven't really groked this. The example above wasn't a joke: you can get the two body problem nailed down perfectly and your code will still fall over when a character stubs their toe or bounces off a wall.

klodolph 6y ago

Something that’s surprisingly tricky to get working well in Unity is to have the player hold an item in first-person perspective and still make that item a physics object. The camera will update at one rate and the physics objects will update at another. It’s easy to end up with an object that jitters horribly as you move it around.

DavidVoid 6y ago

On a related note, Blizzard added a feature to Overwatch about half a year ago that enables the processing of mouse input at 1000Hz! Or well, it doesn't process it at that rate, but it figures out where you were aiming when you fired, even if you fired right between two ticks (or frames). The videos in their blog post [1] explain it much better than I can. [1] https://us.forums.blizzard.com/en/overwatch/t/new-feature-high-precision-mouse-input-gameplay-option/422094 https://us.forums.blizzard.com/en/overwatch/t/new-feature-hi...