My benchmarks show that the price is acceptable
Well, except to people who have a hard requirement that there never be this unpredictable, infrequent longer delay you mention.
Well, except to people who have a hard requirement that there never be this unpredictable, infrequent longer delay you mention.
*: ignoring deliberately esoteric cases, like Doom on a hard real-time system.
(This is not to say the OP has any such issues in its context.)
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.
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.
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.
/me shivers at the recollection
We have way better hardware abstractions in the OS today, which I would agree makes modern development easier overall.
Different world. So much easier now.
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.
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.
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.
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.
Right. This is why lockstep deterministic (LSD) games are bound to the SLOWEST player's machine.
No LSD game in existence crashes the game if one player's machine falls behind. Instead you either pause the simulation for all players until they catch up or you slow down time itself.
Source: shipped RTS games that were lockstep deterministic.
Network latency is a thing and your state management subsystem absolutely has to be fault tolerant.
Deterministic gameplay means after the same x frames with the same external inputs you will end up with the same state y on different hardware. Therefore we only need to make sure the clients stay within a reasonable margin. We can do this by waiting for all players inputs so moving at the slowest speed possible which is the lock-step method. Or we can change our measured frame time so each tick (which still ticks the same amount of sim time) is seen as faster or slower. That way we can track the other frames that other clients have completed from the input they send and slow or speed ourselves up to maintain a decent margin. This is the scheme used in rollback networking as the naïve implementation where this isn’t the case forces all rollbacks onto the faster machine.
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.
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.
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.