6 ms·

It's a requirement for any game that needs a reliable frame rate. Unpredictable delays during frame rendering cause jank. (This is not to say the OP has any s

It's a requirement for any game that needs a reliable frame rate. Unpredictable delays during frame rendering cause jank. (This is not to say the OP has any such issues in its context.)

deleted 3y ago
[deleted]
electroly 3y ago
This is usually called "soft realtime" -- you want it to be fast but it's not wrong if it misses deadlines. It doesn't violate correctness of the system to miss a deadline. In a "hard realtime" system, it is a fatal error if the system misses a deadline because correctness is violated. I presume this difference is what OP is talking about. Games are never hard realtime; missing frame deadlines reduces user experience but it doesn't break the game. Hard realtime is things like industrial motion control, automotive and aviation electronics, pacemakers, etc.
- jefftk 3y ago
  > Games are never hard realtime Depends how high your standards are! One of the things that makes playing old games on the original hardware really satisfying is how consistent they are.
  - brokencode 3y ago
    Those old games could be so consistent because the software and hardware were both so incredibly simple compared to today. Today, a PC game has to work on a large range of hardware that has come out over the past 5+ years. And there are GPU features that are only available on certain cards, like hardware ray tracing and things like DLSS and FSR for upscaling. And the game engines are incredibly more complex today to handle modern expectations, with dynamic lighting and shadows, huge maps, etc. It doesn’t matter what your standards are. Hard realtime just isn’t realistic or even possible any more, except maybe in a game that would be considered truly primitive by today’s standards.
    - EliRivers 3y ago
      I am sure I have memories of how hard it was to support a range of hardware when I had to write specifically for each piece. When I had to write separately for a Soundblaster card and an Adlib and a Disney SoundSource and a Roland and a Gravis. And that was just the sound cards. Writing for different hardware became so much easier when OpenGl and DirectX came into being. Suddenly I just had to write to these APIs. I think I'm disagreeing with you. Supporting multiple hardware configuration way back when was so much harder than doing it today.
      - Yoric 3y ago
        Oh gosh, the many different variants of SVGA that existed back in the days... /me shivers at the recollection
      - gamacodre 3y ago
        Yeah, and Tandy graphics were different from EGA or VGA, just enough that you needed to write different display code for them. And you had to get the user to tell you which ports/IRQ numbers half of their hardware was configured at. We have way better hardware abstractions in the OS today, which I would agree makes modern development easier overall.
        EliRivers 3y ago
        Oh yes, that brings it all back. Having the user tell me the IRQ and also DMAs and... I'm sure there was more. Sometimes the user would end up having to open up the PC and reseat physical jumpers on hardware cards to have the cards use values that were both offered by the software and not clashing with anything else. Different world. So much easier now.
- munificent 3y ago
  > Games are never hard realtime; missing frame deadlines reduces user experience but it doesn't break the game. It depends on whether the game is multi-player and, if so, how it keeps the different players in sync with each other. Games that rely on deterministic gameplay can desync (two players don't see the same world state) and abort if one player's simulation drops a frame while the other doesn't.
  - Groxx 3y ago
    If you have multiplayer like this, you absolutely do not have a hard requirement on frame latency. You don't control network latency spikes. Latency tolerance is a hard requirement, or you will have constant problems and likely be unplayable. Or custom networking and hardware stacks, which is deep into esoteric territory.
  - electroly 3y ago
    That's still just a degradation of user experience and not a fatal fault. Indeed, support for running in desynced mode is written is because they know deadlines can be missed. In hard realtime, deadlines can't be missed. There's no recovery; it's a critical fault and you have to halt or failover to a backup.
    - munificent 3y ago
      > That's still just a degradation of user experience and not a fatal fault. I don't know how you'd describe a game spontaneously aborting not a "fatal fault". Yes, it's not turning off someone's pacemaker, but within the scope of what a game is able to do, kicking the player back to the matchmaking screen in the middle of a game is about as fatal as it gets.
      - fluoridation 3y ago
        That's only going to happen if the client has such a massive network latency spike that the server thinks it's disconnected. At least half a second, possibly more. You're never going to get that kind of delay from synchronizing threads, unless the process totally deadlocks. EDIT: Well, there is one situation where you might get delays like that: if the computer is so woefully inadequate to run the game that it consistently misses frame deadlines by several hundred milliseconds. Of course, in such a situation a different concurrent algorithm wouldn't have solved anything anyway.
- djmips 3y ago
  I would say that an exception could be made for VR games where any frame rate 'jank' causes an uncomfortable experience and can lead to increased simulator sickness.
  - forrestthewoods 3y ago
    VR games almost all use Unity and Unreal. They drop frames left and right. VR platforms use extremely complex time warp algorithms to hide the jank. So you're not wrong. VR games are much more susceptible to dropped frames causing problems. But it both happens and is hidden remarkably well.
- deleted 3y ago
  [deleted]
djmips 3y ago
"Unpredictable delays during frame rendering cause jank" This is usually not serious inflicted and the presentation threads will be higher priority than the simulation in order to minimize visual 'jank' Lockfree game code ain't fixing jank from the OS.
- deleted 3y ago
  [deleted]
- snvzz 3y ago
  >Lockfree game code ain't fixing jank from the OS. Latency is like a chain. Every link matters. A game engine programmer can't do a thing about the OS, but can still keep latency bounded in the code under their control.

It's a requirement for any game that needs a reliable frame rate. Unpredictable delays during frame rendering cause jank. (This is not to say the OP has any such issues in its context.)

deleted 3y ago

[deleted]

electroly 3y ago

This is usually called "soft realtime" -- you want it to be fast but it's not wrong if it misses deadlines. It doesn't violate correctness of the system to miss a deadline. In a "hard realtime" system, it is a fatal error if the system misses a deadline because correctness is violated. I presume this difference is what OP is talking about. Games are never hard realtime; missing frame deadlines reduces user experience but it doesn't break the game. Hard realtime is things like industrial motion control, automotive and aviation electronics, pacemakers, etc.

jefftk 3y ago
> Games are never hard realtime Depends how high your standards are! One of the things that makes playing old games on the original hardware really satisfying is how consistent they are.
- brokencode 3y ago
  Those old games could be so consistent because the software and hardware were both so incredibly simple compared to today. Today, a PC game has to work on a large range of hardware that has come out over the past 5+ years. And there are GPU features that are only available on certain cards, like hardware ray tracing and things like DLSS and FSR for upscaling. And the game engines are incredibly more complex today to handle modern expectations, with dynamic lighting and shadows, huge maps, etc. It doesn’t matter what your standards are. Hard realtime just isn’t realistic or even possible any more, except maybe in a game that would be considered truly primitive by today’s standards.
  - EliRivers 3y ago
    I am sure I have memories of how hard it was to support a range of hardware when I had to write specifically for each piece. When I had to write separately for a Soundblaster card and an Adlib and a Disney SoundSource and a Roland and a Gravis. And that was just the sound cards. Writing for different hardware became so much easier when OpenGl and DirectX came into being. Suddenly I just had to write to these APIs. I think I'm disagreeing with you. Supporting multiple hardware configuration way back when was so much harder than doing it today.
    - Yoric 3y ago
      Oh gosh, the many different variants of SVGA that existed back in the days... /me shivers at the recollection
    - gamacodre 3y ago
      Yeah, and Tandy graphics were different from EGA or VGA, just enough that you needed to write different display code for them. And you had to get the user to tell you which ports/IRQ numbers half of their hardware was configured at. We have way better hardware abstractions in the OS today, which I would agree makes modern development easier overall.
      - EliRivers 3y ago
        Oh yes, that brings it all back. Having the user tell me the IRQ and also DMAs and... I'm sure there was more. Sometimes the user would end up having to open up the PC and reseat physical jumpers on hardware cards to have the cards use values that were both offered by the software and not clashing with anything else. Different world. So much easier now.
munificent 3y ago
> Games are never hard realtime; missing frame deadlines reduces user experience but it doesn't break the game. It depends on whether the game is multi-player and, if so, how it keeps the different players in sync with each other. Games that rely on deterministic gameplay can desync (two players don't see the same world state) and abort if one player's simulation drops a frame while the other doesn't.
- Groxx 3y ago
  If you have multiplayer like this, you absolutely do not have a hard requirement on frame latency. You don't control network latency spikes. Latency tolerance is a hard requirement, or you will have constant problems and likely be unplayable. Or custom networking and hardware stacks, which is deep into esoteric territory.
- electroly 3y ago
  That's still just a degradation of user experience and not a fatal fault. Indeed, support for running in desynced mode is written is because they know deadlines can be missed. In hard realtime, deadlines can't be missed. There's no recovery; it's a critical fault and you have to halt or failover to a backup.
  - munificent 3y ago
    > That's still just a degradation of user experience and not a fatal fault. I don't know how you'd describe a game spontaneously aborting not a "fatal fault". Yes, it's not turning off someone's pacemaker, but within the scope of what a game is able to do, kicking the player back to the matchmaking screen in the middle of a game is about as fatal as it gets.
    - fluoridation 3y ago
      That's only going to happen if the client has such a massive network latency spike that the server thinks it's disconnected. At least half a second, possibly more. You're never going to get that kind of delay from synchronizing threads, unless the process totally deadlocks. EDIT: Well, there is one situation where you might get delays like that: if the computer is so woefully inadequate to run the game that it consistently misses frame deadlines by several hundred milliseconds. Of course, in such a situation a different concurrent algorithm wouldn't have solved anything anyway.
djmips 3y ago
I would say that an exception could be made for VR games where any frame rate 'jank' causes an uncomfortable experience and can lead to increased simulator sickness.
- forrestthewoods 3y ago
  VR games almost all use Unity and Unreal. They drop frames left and right. VR platforms use extremely complex time warp algorithms to hide the jank. So you're not wrong. VR games are much more susceptible to dropped frames causing problems. But it both happens and is hidden remarkably well.
deleted 3y ago
[deleted]

djmips 3y ago

"Unpredictable delays during frame rendering cause jank" This is usually not serious inflicted and the presentation threads will be higher priority than the simulation in order to minimize visual 'jank' Lockfree game code ain't fixing jank from the OS.

deleted 3y ago
[deleted]
snvzz 3y ago
>Lockfree game code ain't fixing jank from the OS. Latency is like a chain. Every link matters. A game engine programmer can't do a thing about the OS, but can still keep latency bounded in the code under their control.