3 ms·

Tying physics to framerate at all is a mistake. Like, should be filed as a bug mistake. There's no scenario in which that's desirable. And yet even Rockstar g

Tying physics to framerate at all is a mistake. Like, should be filed as a bug mistake. There's no scenario in which that's desirable. And yet even Rockstar gets it wrong. (GTA V has several framerate dependent bugs)

JoshTriplett 6mo ago
I completely agree, but it's an easy mistake to make.
Keyframe 6mo ago
not framerate of rendering but physics running at (its own) fixed frame rate.
- nottorp 6mo ago
  Every game logic update, not only physics, should run on a timer that's fully independent from the frame rate. The only place where that doesn't matter is fixed hardware - i.e. old generation consoles, before they started to make "pro" upgrades.
  - JoshTriplett 6mo ago
    > i.e. old generation consoles, before they started to make "pro" upgrades. And before it was realistically possible to port a game to run on multiple consoles without a complete rewrite.
- bregma 6mo ago
  I think you mean timestep. The video frames get updated on one timestep (the so-called "frame rate" because it is the rate at which video frames get redrawn, the inverse of its timestep), physics gets updated on a separate timestep, and gameplay or input or network polling can be updated on its own timestep.
  - Keyframe 6mo ago
    pretty much, over the dozen or so game and rendering engines I made over the decades name mutated from tick to timestep to frame (rate) to refresh rate (hz) to tick again.. it doesn't matter as long as every system is decoupled and rendering is unbounded (if hardware/display combo supports it). This needs thinking from day one. Cool stuff you can do then is determinism, you can do independent timers which go forward, halt, backward in time, different speed multipliers over those (so some things run slower, faster, everything goes slower / faster), etc.
mrob 6mo ago
It's desirable for arcade games, which have fixed hardware including the display. There's no possibility of upgrading for better framerate, and the game can be designed so slowdown is rare or non-existent. Tying the physics to the framerate gives you very low and very consistent input latency with minimum developer effort.
- Grimblewald 6mo ago
  Right, all valid points, but consider the scale of a game like those coming out of rockstar. I'd understand for indie games and arcade games, but a single player rpg that will likely never be seen in arcade settings? Seems odd to me to see it here. Rockstar has the resources to do it properly, one would think, no?
  - JoshTriplett 6mo ago
    Suppose you don't care as much about replays, and you're willing to use other tricks to "cheat" on multiplayer sync instead (because most AAA titles seem to have multiplayer these days). Suppose, instead, your top priority is visual fidelity and being perceived as having cutting-edge graphics. You want maximum computational effort going into letting the gamers with a top-of-the-line GPU render on their 360FPS monitor. And you want lots of objects and realistic physics. If you run physics on a global timer, you could run it at a slower rate and try to fake some of those frames (extrapolating intermediate positions of objects), which is complex. Or you could run it at a faster rate, and every frame has real physics updates, and then it's taking time you could be using for graphics or something else that you think sells better. And there are ways around that, too, but they're complicated and your team is busy and they aren't what your engine gives you for free...

JoshTriplett 6mo ago

I completely agree, but it's an easy mistake to make.

Keyframe 6mo ago

not framerate of rendering but physics running at (its own) fixed frame rate.

nottorp 6mo ago
Every game logic update, not only physics, should run on a timer that's fully independent from the frame rate. The only place where that doesn't matter is fixed hardware - i.e. old generation consoles, before they started to make "pro" upgrades.
- JoshTriplett 6mo ago
  > i.e. old generation consoles, before they started to make "pro" upgrades. And before it was realistically possible to port a game to run on multiple consoles without a complete rewrite.
bregma 6mo ago
I think you mean timestep. The video frames get updated on one timestep (the so-called "frame rate" because it is the rate at which video frames get redrawn, the inverse of its timestep), physics gets updated on a separate timestep, and gameplay or input or network polling can be updated on its own timestep.
- Keyframe 6mo ago
  pretty much, over the dozen or so game and rendering engines I made over the decades name mutated from tick to timestep to frame (rate) to refresh rate (hz) to tick again.. it doesn't matter as long as every system is decoupled and rendering is unbounded (if hardware/display combo supports it). This needs thinking from day one. Cool stuff you can do then is determinism, you can do independent timers which go forward, halt, backward in time, different speed multipliers over those (so some things run slower, faster, everything goes slower / faster), etc.

mrob 6mo ago

It's desirable for arcade games, which have fixed hardware including the display. There's no possibility of upgrading for better framerate, and the game can be designed so slowdown is rare or non-existent. Tying the physics to the framerate gives you very low and very consistent input latency with minimum developer effort.

Grimblewald 6mo ago
Right, all valid points, but consider the scale of a game like those coming out of rockstar. I'd understand for indie games and arcade games, but a single player rpg that will likely never be seen in arcade settings? Seems odd to me to see it here. Rockstar has the resources to do it properly, one would think, no?
- JoshTriplett 6mo ago
  Suppose you don't care as much about replays, and you're willing to use other tricks to "cheat" on multiplayer sync instead (because most AAA titles seem to have multiplayer these days). Suppose, instead, your top priority is visual fidelity and being perceived as having cutting-edge graphics. You want maximum computational effort going into letting the gamers with a top-of-the-line GPU render on their 360FPS monitor. And you want lots of objects and realistic physics. If you run physics on a global timer, you could run it at a slower rate and try to fake some of those frames (extrapolating intermediate positions of objects), which is complex. Or you could run it at a faster rate, and every frame has real physics updates, and then it's taking time you could be using for graphics or something else that you think sells better. And there are ways around that, too, but they're complicated and your team is busy and they aren't what your engine gives you for free...