Live data from Hacker News

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

github.com

101–110 of 183 posts

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

#101

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.

Lockstep simulation can't be hard tied to frame rate. Two computers will never have precisely the same frame timing -- even if they are running identical video modes, clocks are only accurate to within a tolerance and will diverge. The simulation has to allow for simulation ticks running independently from rendering frames.

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

#102

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…

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.

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

#103
post #44

Earlier quoted context omitted.

It's probably fair to claim that zero* game developers have this hard requirement. At best they have a strong desire which might be partially backed up by benchmarks and squinting hard enough. *: ignoring deliberately esoteric cases, like Doom on a hard real-time system.

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

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

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

#104

Earlier quoted context omitted.

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…

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…

Oh gosh, the many different variants of SVGA that existed back in the days...

/me shivers at the recollection

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

#105

Earlier quoted context omitted.

A bit more than that since Xbox runs Windows too.

July console sales: PS5: 1.2m Switch: 950k Xbox: 370k Xbox accounts for just 17% of total console sales in July Both Switch and PS5 are FreeBSD based If we count the whole period of the current gen of each vendors, it only accounts for 13%, it's not big https://www.vgchartz.com/

Actually its only the PS5 that's FreeBSD based. Switch runs a completely proprietary Nintendo OS that borrows a lot from Android.

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

#106
post #25

Earlier quoted context omitted.

Forgive me if it’s common knowledge, but what’s wrong with SDL2 in this case? Broadly speaking, I feel as though there is largely positive sentiment around the SDL project, no?

I have nothing against the SDL project. I have everything against the DirectMedia style api of 1997. I get that people are actively developing with it and that roadmap towards 3.0 is getting close but my experience is it’s designed for legacy games, legacy rendering styles, legacy ABI’s. No one is shipping games for Dreamcast or PS2. 2/3rds of the library is dead code when working with Vulkan.

TIL Unreal 5 based games were "legacy"

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

#107
post #105

Earlier quoted context omitted.

July console sales: PS5: 1.2m Switch: 950k Xbox: 370k Xbox accounts for just 17% of total console sales in July Both Switch and PS5 are FreeBSD based If we count the whole period of the current gen of each vendors, it only accounts for 13%, it's not big https://www.vgchartz.com/

Actually its only the PS5 that's FreeBSD based. Switch runs a completely proprietary Nintendo OS that borrows a lot from Android.

It borrows very little from Android - I think it mostly draws some parts from stagefright.

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

#108
post #102

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…

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.

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.

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

#109

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.

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

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.

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

#110

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

Got bad news for you about what the console SDKs run on

(Also, the consoles don't run Linux)

Post reply on HN