Live data from Hacker News

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

github.com

61–70 of 183 posts

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

#61
post #42

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?

No, and if you accept it as a house then this is a recipe for developing a bad habit of leaving a trail of half finished projects in your wake.

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

#62

Earlier 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…

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

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

#63
post #2

The 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?

I hope the author is not picturing developers using his engine.

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

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

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

#65

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

Agree, I might've stretched It a bit. Your descriptions is more accurate.

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

#66
post #62

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

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.

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

#67

Earlier 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…

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

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 .

bullshit, consoles/mobile are bigger markets than PC/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

#69

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

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

#70

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.

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.
Post reply on HN