4 ms·

You're right on Batman and the general theme, so I upvoted you, but you're totally wrong about FO4. Physics are always tied to framerate. There is not a game p

You're right on Batman and the general theme, so I upvoted you, but you're totally wrong about FO4. Physics are always tied to framerate. There is not a game physics library in wide use that is independent of update rate. In practice what usually happens is that the physics library has an internal tick rate (say every 1ms or every 2ms) and every frame N physics ticks occur to catch up. Without this, the physics sim would be dangerously unstable (and in practice, it still is). There are many other places where game code is typically framerate dependent, not just physics. Even games that are 'framerate independent' are often framerate dependent in very subtle ways, such that players with high or low framerates gain an advantage or experience unique bugs. Most parts of a game are not continuous equations that you can perfectly evaluate at any point in time; there are always 'frames'. So ultimately, this is not some unique cardinal sin FO4 committed. It's just another in a long series of Bethesda titles that ship incredibly buggy and broken and don't get fixed, largely as a result of the way they build software. The incredible scope of their games is a factor, though, as building games that large is EXTREMELY HARD. Ultimately you should consider people talking about FO4 framerates that way to be in the same bucket as the types who get vigorously upset about a game being locked to 30fps: Uninformed.

ufo 11y ago
> Physics are always tied to framerate Why does it have to be like this? I would think the more robust approach would be to decouple the simulation from the rendering and display interpolated frames if the renderer framerate is higher than the simulation framerate.
- hacker_9 11y ago
  Whilst it's nice to think in separate concepts such as 'physics' and 'rendering', in reality all these things are tightly coupled together in code. For example collisions inform physics which informs collisions which informs animations etc. Also with memory being so scarce in AAA games you have to evaluate the cost of using separate threads for different actions, which leads to problems of resource sharing, deadlocks, syncing of update/render loops etc. Bungie did a talk on their multi threaded renderer for Destiny. Google it if you want to see how complex the design can get, and how it affects the whole game process.
  - ufo 11y ago
    Thanks. Apparently fallout4 has a bunch of bugs on higher-end PCs because and I was wondering why they would couple things like that. I guess the harsh restrictions of gamedev explain it a bit then... btw, I think this is the video the parent mentioned, in case anyone is interested: https://www.youtube.com/watch?v=0nTDFLMLX9k https://www.youtube.com/watch?v=0nTDFLMLX9k
- lispit 11y ago
  Many engines do exactly that. http://gafferongames.com/game-physics/fix-your-timestep/ http://gafferongames.com/game-physics/fix-your-timestep/
lispit 11y ago
>Physics are always tied to framerate. There is not a game physics library in wide use that is independent of update rate. In practice what usually happens is that the physics library has an internal tick rate (say every 1ms or every 2ms) and every frame N physics ticks occur to catch up. Without this, the physics sim would be dangerously unstable (and in practice, it still is). This is called a fixed timestep, and is not what people mean when they say "physics is tied to the framerate", referring to the rendering framerate and generally instead meaning that you pass the actual delta time elapsed between rendering frames into the physics simulation, which can cause bugs at extremely high or low framerates. I have no idea if FO4 works this way, but many engines do (even if it is usually a bad idea), so it's not completely outside the realm of possibility.
- yoklov 11y ago
  The reason is that there are tradeoffs. Fixing the timestep guarantees a frame of latency, but most (all?) integration methods used to simulate physics break down with wildly variable timesteps. Tying simulation to framerate is often the best choice, when you consider that most hardware is average, it minimizes latency for the average user, and results with a more accurate simulation, so long as people keep vsync on (why do you need framerate greater than your monitor's refresh rate anyway...).
  - lispit 11y ago
    >Tying simulation to framerate is often the best choice, when you consider that most hardware is average, it minimizes latency for the average user, and results with a more accurate simulation It can be, if you either are on a fixed hardware platform or have both modest demands and a framelimiter in place to keep things from going off the rails. But in return you pay with a great source of nondeterminism that can cause maddening bugs, break replays, and hinder synchronization in networked games. >so long as people keep vsync on (why do you need framerate greater than your monitor's refresh rate anyway...) Two things going on here. Vsync is theoretically a great idea (that worked perfectly in practice on countless simpler platforms in the past), but due to driver flaws and the realities of preemptive multitasking introduces a noticeable additional frame or two of latency on every PC I've used in the past decade or so, whether playing a game or just using regular desktop applications. My guess is that the OS scheduler isn't precise enough to keep applications from barely missing a present deadline (thus causing unnecessary stuttering), so driver devs force triple buffering when vsync is enabled to compensate, giving you a smooth but unresponsive presentation. It really sucks that I have to toggle desktop composition (and thus, vsync) on and off to fix stuttering in one application or tearing in another, but somewhere in the Lovecraftian horror that is Windows, someone screwed up. The other is "why do you need framerate greater than your monitor's refresh rate anyway," and the answer is "to provide the lowest latency and smoothest presentation possible within the constraints of a preemptive multitasking OS." In a perfect world, a game would know exactly how long it would take to simulate and render a frame, and would wait as long as possible before doing so, so that the most up-to-date input from the keyboard, mouse, and network could be used to display a frame with the least amount of latency factored into it to the player. This is not a perfect world, but you can get a similar effect (at a greater CPU and GPU cost) by rendering multiple superfluous frames, so that whichever one happens to be presented is much closer to the ideal than the one you'd see if you rendered the frame at the start of the 16ms then yielded for the rest of it. This is part of why you often see "pro e-sports" types turning the graphics settings down to comical levels, by the way. Not only to lessen the threat of a completely missed frame due to a spike in visual complexity, but also so that they can run their game with the framelimiter off.
jonesb6 11y ago
I think part of his point was that such a drastic effect on physics/framerate as the Bethesda studio allowed is inexcusable. Honest question: is such a bug excusable/understandable? My impression is that this is something that could've easily been caught in testing. My guess would be that it WAS found but allowed to pass into production. That I believe, is inexcusable for a studio that large.
thescriptkiddie 11y ago
On the contrary, all popular physics engines today (including the one in FO4) do not tie simulation framerate to rendering framerate. That would make the simulation incredibly unstable. Instead, the physics happen in their own thread at a fixed timestep. It's up to the game developer to have enough sense to write non-blocking multi threaded code, but if they do things by the book everything just works. This includes FO4, which contrary to your post does not have a 30 FPS cap (except on consoles).
fenomas 11y ago
> Physics are always tied to framerate. Do you mean "to some framerate"? Obviously physics has to be ticked, but it doesn't have to be ticked at the same rate the game renders. Lots of games and game engines decouple these rates correctly. Likewise, games where the logic runs faster at high visual framerates are hardly that common. Outside of Bethesda, and retro games played on an emulator, I can't recall the last time I saw one.
ionised 11y ago
> Ultimately you should consider people talking about FO4 framerates that way to be in the same bucket as the types who get vigorously upset about a game being locked to 30fps. What? How is being used to higher framerates uninformed? Fallout 4 does not have a 30fps cap on PC, it has 60fps cap. It's unlocking past 60 that causes the physics to shit the bed. Unless you are going to suggest that there is no difference between 30fps and 60fps in gameplay, in which case I would say you are the one that is uninformed.

ufo 11y ago

> Physics are always tied to framerate Why does it have to be like this? I would think the more robust approach would be to decouple the simulation from the rendering and display interpolated frames if the renderer framerate is higher than the simulation framerate.

hacker_9 11y ago
Whilst it's nice to think in separate concepts such as 'physics' and 'rendering', in reality all these things are tightly coupled together in code. For example collisions inform physics which informs collisions which informs animations etc. Also with memory being so scarce in AAA games you have to evaluate the cost of using separate threads for different actions, which leads to problems of resource sharing, deadlocks, syncing of update/render loops etc. Bungie did a talk on their multi threaded renderer for Destiny. Google it if you want to see how complex the design can get, and how it affects the whole game process.
- ufo 11y ago
  Thanks. Apparently fallout4 has a bunch of bugs on higher-end PCs because and I was wondering why they would couple things like that. I guess the harsh restrictions of gamedev explain it a bit then... btw, I think this is the video the parent mentioned, in case anyone is interested: https://www.youtube.com/watch?v=0nTDFLMLX9k https://www.youtube.com/watch?v=0nTDFLMLX9k
lispit 11y ago
Many engines do exactly that. http://gafferongames.com/game-physics/fix-your-timestep/ http://gafferongames.com/game-physics/fix-your-timestep/

lispit 11y ago

>Physics are always tied to framerate. There is not a game physics library in wide use that is independent of update rate. In practice what usually happens is that the physics library has an internal tick rate (say every 1ms or every 2ms) and every frame N physics ticks occur to catch up. Without this, the physics sim would be dangerously unstable (and in practice, it still is). This is called a fixed timestep, and is not what people mean when they say "physics is tied to the framerate", referring to the rendering framerate and generally instead meaning that you pass the actual delta time elapsed between rendering frames into the physics simulation, which can cause bugs at extremely high or low framerates. I have no idea if FO4 works this way, but many engines do (even if it is usually a bad idea), so it's not completely outside the realm of possibility.

yoklov 11y ago
The reason is that there are tradeoffs. Fixing the timestep guarantees a frame of latency, but most (all?) integration methods used to simulate physics break down with wildly variable timesteps. Tying simulation to framerate is often the best choice, when you consider that most hardware is average, it minimizes latency for the average user, and results with a more accurate simulation, so long as people keep vsync on (why do you need framerate greater than your monitor's refresh rate anyway...).
- lispit 11y ago
  >Tying simulation to framerate is often the best choice, when you consider that most hardware is average, it minimizes latency for the average user, and results with a more accurate simulation It can be, if you either are on a fixed hardware platform or have both modest demands and a framelimiter in place to keep things from going off the rails. But in return you pay with a great source of nondeterminism that can cause maddening bugs, break replays, and hinder synchronization in networked games. >so long as people keep vsync on (why do you need framerate greater than your monitor's refresh rate anyway...) Two things going on here. Vsync is theoretically a great idea (that worked perfectly in practice on countless simpler platforms in the past), but due to driver flaws and the realities of preemptive multitasking introduces a noticeable additional frame or two of latency on every PC I've used in the past decade or so, whether playing a game or just using regular desktop applications. My guess is that the OS scheduler isn't precise enough to keep applications from barely missing a present deadline (thus causing unnecessary stuttering), so driver devs force triple buffering when vsync is enabled to compensate, giving you a smooth but unresponsive presentation. It really sucks that I have to toggle desktop composition (and thus, vsync) on and off to fix stuttering in one application or tearing in another, but somewhere in the Lovecraftian horror that is Windows, someone screwed up. The other is "why do you need framerate greater than your monitor's refresh rate anyway," and the answer is "to provide the lowest latency and smoothest presentation possible within the constraints of a preemptive multitasking OS." In a perfect world, a game would know exactly how long it would take to simulate and render a frame, and would wait as long as possible before doing so, so that the most up-to-date input from the keyboard, mouse, and network could be used to display a frame with the least amount of latency factored into it to the player. This is not a perfect world, but you can get a similar effect (at a greater CPU and GPU cost) by rendering multiple superfluous frames, so that whichever one happens to be presented is much closer to the ideal than the one you'd see if you rendered the frame at the start of the 16ms then yielded for the rest of it. This is part of why you often see "pro e-sports" types turning the graphics settings down to comical levels, by the way. Not only to lessen the threat of a completely missed frame due to a spike in visual complexity, but also so that they can run their game with the framelimiter off.

jonesb6 11y ago

I think part of his point was that such a drastic effect on physics/framerate as the Bethesda studio allowed is inexcusable. Honest question: is such a bug excusable/understandable? My impression is that this is something that could've easily been caught in testing. My guess would be that it WAS found but allowed to pass into production. That I believe, is inexcusable for a studio that large.

thescriptkiddie 11y ago

On the contrary, all popular physics engines today (including the one in FO4) do not tie simulation framerate to rendering framerate. That would make the simulation incredibly unstable. Instead, the physics happen in their own thread at a fixed timestep. It's up to the game developer to have enough sense to write non-blocking multi threaded code, but if they do things by the book everything just works. This includes FO4, which contrary to your post does not have a 30 FPS cap (except on consoles).

fenomas 11y ago

> Physics are always tied to framerate. Do you mean "to some framerate"? Obviously physics has to be ticked, but it doesn't have to be ticked at the same rate the game renders. Lots of games and game engines decouple these rates correctly. Likewise, games where the logic runs faster at high visual framerates are hardly that common. Outside of Bethesda, and retro games played on an emulator, I can't recall the last time I saw one.

ionised 11y ago

> Ultimately you should consider people talking about FO4 framerates that way to be in the same bucket as the types who get vigorously upset about a game being locked to 30fps. What? How is being used to higher framerates uninformed? Fallout 4 does not have a 30fps cap on PC, it has 60fps cap. It's unlocking past 60 that causes the physics to shit the bed. Unless you are going to suggest that there is no difference between 30fps and 60fps in gameplay, in which case I would say you are the one that is uninformed.