Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Peredvizhnikov Engine: Lock-free game engine written in C++20

github.com

Post reply on HN
Print view View original

81–90 of 183 posts

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#81

Post by fluoridation »

munificent wrote: post #75
electroly wrote: post #70

Earlier quoted context omitted.

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.

> 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.

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.

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#82

Post by fiddlerwoaroof »

munificent wrote: post #75
electroly wrote: post #70

Earlier quoted context omitted.

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.

> 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.

What I don’t understand here is how missing a frame deadline in this situation (<1/60 of a second or 16ms) is intolerable when typical network latency varies constantly by much more than this. It seems to me that if the latency requirements were this strict you could only support LAN multiplayer.

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#83

Post by dzaima »

munificent wrote: post #67
electroly wrote: post #60

Earlier quoted context omitted.

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…

> 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.

If you want to support players with ping over 16ms, there's no way you're gonna be synchronizing input from one frame to the output of the same frame for another player; there'll necessarily be some latency hiding, at which point any freeze should be coverable via just treating it as a temporarily-high ping and thus temporarily more latency hiding.

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#84

Post by gabereiser »

schmichael wrote: post #50
gabereiser wrote: post #26

Earlier quoted context omitted.

Yes. The mediator in this case is the scheduler. The one that actually calls the asynchronous block. Potentially retrying it if it fails. In the OP’s code, there’s atomic blocks, sequential execution of blocks, stateful blocks, etc for ensuring singular access at a time. The meat here is scheduler.cpp. It uses std::coroutines. This is like async/await in other languages. The scheduler has a queue of work(coroutines)…

Thanks! So the scheduler serializes execution of critical sections? > In this case, messages are passed between work that contains the data. No locks are required at the expense of memory footprint. Are messages copied or moved? If moved is there compile time checking for ownership or runtime debugging tools?

https://en.cppreference.com/w/cpp/language/coroutines

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#85

Post by sigg3 »

Salgat wrote: post #45
hesdeadjim wrote: post #3

It’s quite the stretch to call this a game engine, rather than a tech demo for clever locking strategies.

I wouldn't even call it clever. The Actor model trivializes avoiding locks, since you're letting everything act on stale information (if the actors process concurrently) and then just iterating through their intended actions against a singleton state and resolving those conflicts with sequential code.

Thanks for the summary, mate.

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#88

Post by [deleted] »

devit wrote: post #64

It says that it's actor-based, and sending messages to an actor is equivalent to running the actor function under a mutex, and thus reduces parallelism (in other words, you have N threads sending messages, but only 1 thread running the actor code, so it's just as serialized as a mutex), so while it may technically be "fully lock-free", using actors means that there is no parallelization improvement.

[deleted]

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#89

Post by caconym_ »

munificent wrote: post #75
electroly wrote: post #70

Earlier quoted context omitted.

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.

> 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.

Literally any multiplayer game will have a "fatal fault" if its connection to the other players and/or server is interrupted for long enough, but it seems disingenuous to describe a system tolerant of delays variable across several orders of magnitude, up to hundreds of milliseconds or even full seconds, as "hard real time" in the sense in which the term is generally understood.

Re: Peredvizhnikov Engine: Lock-free game engine written in C++20

#90

Post by onjectic »

devit wrote: post #64

It says that it's actor-based, and sending messages to an actor is equivalent to running the actor function under a mutex, and thus reduces parallelism (in other words, you have N threads sending messages, but only 1 thread running the actor code, so it's just as serialized as a mutex), so while it may technically be "fully lock-free", using actors means that there is no parallelization improvement.

Your right that there is no parallelization improvement, but it does not reduce parallelism either, its just a different(imo easier) way to think about concurrency.

Because it is easier for me to think about it is easier for me to see where things will contend the same resource and actually helps me improve potential parallelism. Once you recognize a particular opportunity where SMP can speed things up, you can stray a way from the actor-model a bit and have multiple threads receiving on your message queue, or if that isn't possible, you can just add more actors and split up the data better.

Post reply on HN