6 ms·

The other reason you want to use a function of time and avoid using state for things like animations is that you don't want animation speed to be frame rate dep

by pdpi 4y ago

The other reason you want to use a function of time and avoid using state for things like animations is that you don't want animation speed to be frame rate dependent.

sublinear 4y ago
Game state isn't usually frame rate dependent either
- creshal 4y ago
  A lot of games have some internal "physics rate" or similarly termed tick rate at which the logical state is updated. The better you can decouple the graphics pipeline from it, the better.
- bluGill 4y ago
  Not anymore, in the past it was. Some games in the 8bit world ran slower in Europe vs the US because Europe TVs used PAL which was 50hz refreshes, while the US had NTSC with 60hz refreshes (some games counted on NTSC being interlaced and so updated at 30hz which made NTSC games slower). IIRC some PC games depended on frame rate as well, but I don't recall any specifics.
  - dpkirchner 4y ago
    Skyrim infamously allows your frame rate to influence game physics, with hilarious results. https://old.reddit.com/r/skyrim/comments/twwqqt/can_someone_tell_me_what_the_actual_fuck_is_going/ https://old.reddit.com/r/skyrim/comments/twwqqt/can_someone_...
    - connicpu 4y ago
      This is one of the traps when you go for the naive approach to framerate independence: simply using the frame delta for stepping your calculations. Results for physics engines are very wacky! It's usually better to step your physics engine at a fixed rate (e.g. 60hz), and make the frequency of steps performed independent of the graphics framerate. Perform some slight interpolation on the position of rendered objects and nobody can tell the difference
  - earthling8118 4y ago
    The original DayZ mod had an issue with this. If your framerate was lower your character would run slower. It's a very subtle effect, but when you ran several km alongside someone with a weaker computer they'd end up further back and you'd have to wait for them to catch up.
- munificent 4y ago
  Render state usually isn't, but internal simulation and physics often updates using a fixed time step because it avoids many many problems caused by variable frame rates. https://gafferongames.com/post/fix_your_timestep/ https://gafferongames.com/post/fix_your_timestep/
j1elo 4y ago
When things aren't done properly, the whole experience can fall down. I recently played Minnit [1], a very small and cute game with a very unique proposal: that you only have 1 minute of gameplay before being warped to a starting point. But time is not checked asynchronously but as a function of the frame rate, so my playthrough was basically sped up and lasted for 45 seconds each time. Turned out I didn't realize until almost the end, when a _very_ difficult movement seemed almost impossible to make in time (I did end up achieving 100% doable things in the game, but it cost me a good amount of attempts!) Gamedevs, please, do not count frames and assume they'll be whatever amount per second you believe they'll be. Because they won't. [1]: https://store.steampowered.com/app/609490/Minit/ https://store.steampowered.com/app/609490/Minit/
- Kiro 4y ago
  Didn't that mean you also moved faster?
  - j1elo 4y ago
    Yes, that's how I was able to complete most parts of the game (which in general isn't difficult at all). But at least one of the extra optional things does get much more difficult if you don't have almost perfect execution, so faster movement speeds were actually a handicap as my control movements had to me much more precise. To be clear: it was at that time that I discovered that some wrong settings in the Steam Deck had been affecting the in-game FPS, so after correcting them and getting to the designed runtime speeds, the challenge got from impossible to barely achievable :)
- __MatrixMan__ 4y ago
  As a newbie in a graphics course I once animated something using xlib and openGL. I hadn't bothered install my graphics card driver, so everything was nice and slow. I brought it into to the professor's office (it was our final) to demo it, and it was so fast on his machine that you couldn't see it. I freaked out, but he had seen that kind of problem before and just sprinkled some sleeps throughout so it was visible to a human and gave me a B.
wolfi008 4y ago
In other words, don't write state, only consume it. (Time is also state.)
barbariangrunge 4y ago
Removing frame rate dependence isn’t central to this concept, it’s almost a coincidental side effect. You can easily remove frame rate dependence in the first example
Pxtl 4y ago
You do that by using delta-t instead of 1 when doing a stateful operation. The fact that a stateless function does it for you automatically is gravy.

by pdpi 4y ago

The other reason you want to use a function of time and avoid using state for things like animations is that you don't want animation speed to be frame rate dependent.

sublinear 4y ago

Game state isn't usually frame rate dependent either

creshal 4y ago
A lot of games have some internal "physics rate" or similarly termed tick rate at which the logical state is updated. The better you can decouple the graphics pipeline from it, the better.
bluGill 4y ago
Not anymore, in the past it was. Some games in the 8bit world ran slower in Europe vs the US because Europe TVs used PAL which was 50hz refreshes, while the US had NTSC with 60hz refreshes (some games counted on NTSC being interlaced and so updated at 30hz which made NTSC games slower). IIRC some PC games depended on frame rate as well, but I don't recall any specifics.
- dpkirchner 4y ago
  Skyrim infamously allows your frame rate to influence game physics, with hilarious results. https://old.reddit.com/r/skyrim/comments/twwqqt/can_someone_tell_me_what_the_actual_fuck_is_going/ https://old.reddit.com/r/skyrim/comments/twwqqt/can_someone_...
  - connicpu 4y ago
    This is one of the traps when you go for the naive approach to framerate independence: simply using the frame delta for stepping your calculations. Results for physics engines are very wacky! It's usually better to step your physics engine at a fixed rate (e.g. 60hz), and make the frequency of steps performed independent of the graphics framerate. Perform some slight interpolation on the position of rendered objects and nobody can tell the difference
- earthling8118 4y ago
  The original DayZ mod had an issue with this. If your framerate was lower your character would run slower. It's a very subtle effect, but when you ran several km alongside someone with a weaker computer they'd end up further back and you'd have to wait for them to catch up.
munificent 4y ago
Render state usually isn't, but internal simulation and physics often updates using a fixed time step because it avoids many many problems caused by variable frame rates. https://gafferongames.com/post/fix_your_timestep/ https://gafferongames.com/post/fix_your_timestep/

j1elo 4y ago

When things aren't done properly, the whole experience can fall down. I recently played Minnit [1], a very small and cute game with a very unique proposal: that you only have 1 minute of gameplay before being warped to a starting point. But time is not checked asynchronously but as a function of the frame rate, so my playthrough was basically sped up and lasted for 45 seconds each time. Turned out I didn't realize until almost the end, when a _very_ difficult movement seemed almost impossible to make in time (I did end up achieving 100% doable things in the game, but it cost me a good amount of attempts!) Gamedevs, please, do not count frames and assume they'll be whatever amount per second you believe they'll be. Because they won't. [1]: https://store.steampowered.com/app/609490/Minit/ https://store.steampowered.com/app/609490/Minit/

Kiro 4y ago
Didn't that mean you also moved faster?
- j1elo 4y ago
  Yes, that's how I was able to complete most parts of the game (which in general isn't difficult at all). But at least one of the extra optional things does get much more difficult if you don't have almost perfect execution, so faster movement speeds were actually a handicap as my control movements had to me much more precise. To be clear: it was at that time that I discovered that some wrong settings in the Steam Deck had been affecting the in-game FPS, so after correcting them and getting to the designed runtime speeds, the challenge got from impossible to barely achievable :)
__MatrixMan__ 4y ago
As a newbie in a graphics course I once animated something using xlib and openGL. I hadn't bothered install my graphics card driver, so everything was nice and slow. I brought it into to the professor's office (it was our final) to demo it, and it was so fast on his machine that you couldn't see it. I freaked out, but he had seen that kind of problem before and just sprinkled some sleeps throughout so it was visible to a human and gave me a B.

wolfi008 4y ago

In other words, don't write state, only consume it. (Time is also state.)

barbariangrunge 4y ago

Removing frame rate dependence isn’t central to this concept, it’s almost a coincidental side effect. You can easily remove frame rate dependence in the first example

Pxtl 4y ago

You do that by using delta-t instead of 1 when doing a stateful operation. The fact that a stateless function does it for you automatically is gravy.