Live data from Hacker News

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

github.com

131–140 of 183 posts

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

#131

Actors is one of the worst programming models possible. It's hard to observe actor-based systems and debug them. The protocol complexity (and complete protocol informality) usually brings much more trouble than any kind of locking/synchronization.

For game dev or in general? I hate using actors for general backend stuff, but for game dev maybe it makes more sense.

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

#132
post #80

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…

Aren't lock free data structures more about reducing the impact of contention than throughput under low contention?

Under a lock free algorithm, we promise that across our entire system, eventually some progress is made. I can't necessarily point at any specific thread of execution and say "This thread makes progress" but I can say that forward progress is made for the system as a whole.

Under a wait free algorithm, we promise that every individual thread eventually makes progress.

Suppose I have one really dumb thread which just goes to sleep for 10 seconds in a loop, as well as other threads which do some actual work. If we're a lock free algorithm, it is OK if the 10-second-sleep thread is always chosen to make progress, its "progress" consists of sleeping for 10 seconds, too bad, try again next time.

With a wait free algorithm, the threads which actually do useful work will also make at least some progress, eventually despite the 10 second sleeper.

Generally we can't say for sure that we e.g. "reduce impact of contention" only that we definitely make some forward progress, on at least one thread eventually.

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

#134
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, because otherwise you wouldn't say "the foundation has been built". You'd say the "the house has been built".

Does a house need a foundation? Yes. Is the foundation the same as the house? No.

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

#135

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/

And what about actual game sales and revenue through things like GamePass. It doesn't help your game if a million people bought a Nintendo Switch if 80% of them only buy Pokémon, Mario Kart and Zelda.

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

#136

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

This model isn't novel, there's been experimental engines using this technique for years now. They're just not practical at scale

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

#137

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…

Yeah, and Tandy graphics were different from EGA or VGA, just enough that you needed to write different display code for them. And you had to get the user to tell you which ports/IRQ numbers half of their hardware was configured at.

We have way better hardware abstractions in the OS today, which I would agree makes modern development easier overall.

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

#139
post #138

Where is the game demo? Also to be considered gaming engine nowadays, you need actual tools, exporters (Maya, 3DSMax, etc.) + who knows what else (collaboration tooling, metrics, alerts)

I disagree—"game engine" does not necessarily mean "thing I can replace Unity or Unreal with".

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

#140
post #18
post #4

All those people who complain about project names squatting on existing words have finally been heard :-D

I tried in it a zxcvbn simulator, and it qualified as a strong password ;)

My experience is that zxcvbn lacks many non-English dictionaries, it often gives false-positives for foreign languages...
Post reply on HN