It’s quite the stretch to call this a game engine, rather than a tech demo for clever locking strategies.
Say you are in the middle of building a house. The foundation has been built and they are framing it up. Is it a house?
Peredvizhnikov Engine: Lock-free game engine written in C++20
61–70 of 183 posts
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#62Earlier quoted context omitted.
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.)
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…
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.
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#63The painting used is Barge Haulers on the Volga - https://en.m.wikipedia.org/wiki/Barge_Haulers_on_the_Volga Can someone please expand on the significance of this achievement to someone used to shooting their foot off in C++ in a predominantly single threaded manner?
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#64Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#65Earlier quoted context omitted.
They were not the slaves, but unionized workers: https://en.m.wikipedia.org/wiki/Burlak
AFAIU an артель artelʼ usually did not engage in collective bargaining as such, so calling it a union is not really accurate; you might compare it to a guild but I think there’s no implicaton of a monopoly on a particular trade either. The most accurate description I can think of is perhaps a cooperative combined with a mutual insurance fund.
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#66Earlier 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 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.
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#67Earlier quoted context omitted.
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.)
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…
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.
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#68> At the moment, the only supported platform is Linux. Regardless of your feelings on the status quo, there is one thing you must do when building a game engine if you want it to succeed: support Windows .
PC is just less than 1/3 of the whole picture
https://www.data.ai/en/insights/mobile-gaming/2022-gaming-sp...
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#69Earlier 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.
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.
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#70Earlier 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.