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

121–130 of 183 posts

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

#121

Post by squeaky-clean »

fiddlerwoaroof wrote: post #82
munificent wrote: post #75

Earlier quoted context omitted.

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

The only scenario I can imagine is some interactive game installation at Disney/etc. But there'd still be no actual benefit over an architecture more lenient to timing deviations.

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

#122

Post by hankman86 »

It’s licensed under GPL3, where the developer suggests individually negotiating a license for commercial projects. I am not sure this is a good approach given the early stage of this project. Video game development is already commercially and technically risky enough.

I cannot see game developers lining up to even try out this unproven technology when they have no sense of what the eventual fees will be.

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

#123

Post by gjvc »

hankman86 wrote: post #122

It’s licensed under GPL3, where the developer suggests individually negotiating a license for commercial projects. I am not sure this is a good approach given the early stage of this project. Video game development is already commercially and technically risky enough. I cannot see game developers lining up to even try out this unproven technology when they have no sense of what the eventual fees will be.

quoting https://github.com/eduard-permyakov/peredvizhnikov-engine

The source code of Peredvizhnikov Engine is freely available under the GPLv3 license. However, I may grant permission to use parts or all of the code under a different license on a case-by-case basis. Please inquire by e-mail.

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

#124

Post by rowanG077 »

smallstepforman wrote: post #17

I have an Actor framework which uses a vanilla std::deque for method pointers, and to add messages to the queue, the locking technique is a Benaphore (the original Futex, which uses an atomic and a locking primitive, with the twist that my locking primitive is a combo of spinlock/mutex based on retry count). Nothing special. Benchmarks show that very rarely does the message push function block, and the chance of an O…

I gather from your comment that lock-free is actually the best choice for videogames. Where consistent frame timing should be paramount.

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

#125

Post by [deleted] »

hankman86 wrote: post #122

It’s licensed under GPL3, where the developer suggests individually negotiating a license for commercial projects. I am not sure this is a good approach given the early stage of this project. Video game development is already commercially and technically risky enough. I cannot see game developers lining up to even try out this unproven technology when they have no sense of what the eventual fees will be.

[deleted]

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

#127

Post by pramalhe »

smallstepforman wrote: post #17

I have an Actor framework which uses a vanilla std::deque for method pointers, and to add messages to the queue, the locking technique is a Benaphore (the original Futex, which uses an atomic and a locking primitive, with the twist that my locking primitive is a combo of spinlock/mutex based on retry count). Nothing special. Benchmarks show that very rarely does the message push function block, and the chance of an O…

[dead]

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

#128

Post by tialaramex »

smallstepforman wrote: post #17

I have an Actor framework which uses a vanilla std::deque for method pointers, and to add messages to the queue, the locking technique is a Benaphore (the original Futex, which uses an atomic and a locking primitive, with the twist that my locking primitive is a combo of spinlock/mutex based on retry count). Nothing special. Benchmarks show that very rarely does the message push function block, and the chance of an O…

> the original Futex

The "Benaphore" was a pretty old idea, but the Futex isn't just "Oh it's a Benaphore but Linux" the essential trick is that you don't actually need a kernel object - your "locking primitive" at all, and that idea is where this goes from "Yeah, everybody knows that" to OK, our OS should add this feature ASAP.

Instead of an OS synchronisation object which is used to handle conflicts, with the futex design the OS carries a list of address -> thread mappings. If a thread T is asleep on a futex at address X, the address X goes in the list pointing to thread T. When the OS is asked to wake the X futex, it walks the list and wakes T.

The give away is the limits. For something like Benaphores you're constrained, these are a costly OS wide resource, I think BeOS only allowed 65536 per machine or something. But a Futex is just memory, so there's no reason to have any limit at all.

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

#129

Post by hot_gril »

mrkeen wrote: post #118
jstimpfle wrote: post #98

Earlier quoted context omitted.

> sending messages to an actor is equivalent to running the actor function under a mutex Where does it say that? In my understanding actor model means message-passing with asynchronous execution. So quite the contrary, actor model allows N threads executing in parallel given N actors.

Whenever I read any press about actors or goroutines, they say the same thing about preventing races (and the need for explicit locking) through share-nothing concurrency. It's easy to scatter the computations, but they never go on to explain how to gather them back up. You're going to render one frame to the screen. Did multiple actors have a write-handle into the frame buffer? What about collisions, does each entit…

One way or another, there has to be a master thread that gathers things back. So instead of a mutex, you have a supervisor.

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

#130

Post by hot_gril »

WhereIsTheTruth wrote: post #68
edfletcher_t137 wrote: post #47

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

Rude way of putting it, but yeah, mobile dwarfs everything.
Post reply on HN