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

141–150 of 183 posts

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

#141

Post by datameta »

datameta wrote: 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?

As an addendum - a fair portion here should be in one way or another familiar with Ilya Repin's Reply of the Zaporozhian Cossacks (aka Zaporozhian Cossacks are Writing a Letter to the Turkish Sultan) https://en.m.wikipedia.org/wiki/Reply_of_the_Zaporozhian_Cos...

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

#142

Post by corethree »

WhereIsTheTruth wrote: post #119
corethree wrote: post #95

Earlier quoted context omitted.

He's probably referring to the Desktop/laptop market. In which case windows controls like 90%.

Title is: "Peredvizhnikov Engine is a fully lock-free game engine written in C++20 " A Game Engine targets various platforms A "video-game" is not something exclusive to desktop/laptop windows market

Right but a toolchain that targets anything else other then a desktop is not straightforward to find or setup.

Toy game engines like this are in the majority of cases used on desktop.

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

#143

Post by jstimpfle »

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…

How to gather them up, I guess messages again? It depends on the situation how easy it is, and yes I would assume typically not very.

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

#144

Post by xwdv »

adamrezich wrote: post #139
malkia wrote: 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".

Not even asking for that much. Any game demo would be appreciated.

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

#145

Post by legosexmagic »

hot_gril wrote: post #131
pshirshov wrote: post #113

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.

Actors tend to lead to bloated incomprehensible code. Even when you do want game objects to look like independent message passing actors. Faking it is always easier.

Actors are self defeating because they turn everything into a distributed system.

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

#146

Post by p1necone »

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

I feel like it's a mistake to consider mobile games as being part of the same market as PC/console games.

Sure they're both "games" but I don't know that they're competing for the same set of users - either people play one or the other, or the people that do crossover in both markets are probably playing PC/console games at home and mobile games on the bus or train.

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

#147

Post by rstat1 »

GranPC wrote: post #107
rstat1 wrote: post #105

Earlier quoted context omitted.

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.

Also borrows the whole of its compositor "nvnflinger" from Android's "SurfaceFlinger".

I'd call that a pretty significant piece.

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

#148

Post by rstat1 »

WhereIsTheTruth wrote: post #116
rstat1 wrote: post #105

Earlier quoted context omitted.

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

A mix of the two "partially Unix-like via certain components which are based on FreeBSD and Android" https://en.wikipedia.org/wiki/Nintendo_Switch_system_softwar...

from the same article

"it is based on a proprietary microkernel"

"....Despite popular misconceptions to the contrary, Horizon (the Switch's OS) is not largely derived from FreeBSD code, nor from Android..."

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

#149

Post by gabereiser »

rstat1 wrote: post #106
gabereiser wrote: post #28

Earlier quoted context omitted.

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"

They really only use it for Linux window and audio because there’s so many ways to skin a disto.

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

#150

Post by gabereiser »

nickelpro wrote: post #97
gabereiser wrote: post #93

Earlier quoted context omitted.

For what? Working with Vulkan? Or a windowing library? Personally I use a mix of glfw and native windowing on mobile, which is surprisingly simple for a gfx context window and this gets me to triangle. SDL2 is about the same amount of boilerplate code only in SDL_Thing form. Now, if I was writing a game that needed to be shipped on everything possible and I can’t afford Unity or Unreal, SDL is a viable choice. MonoGa…

As with most SDL usage, it merely provides a rendering context and an input abstraction. That's almost nothing, its boilerplate you don't want to write. Which particular lib you grab that boilerplate from, SDL, GLFW, fucking GLEW, whatever, it doesn't matter. SDL is a widely accepted library for doing so and it's fine . If you want more complete input handling you'll be using the platform APIs directly.

And surfaces, and audio… yeah I know. For tinkering and learning, sure. If you’re going to build an engine, pull that boilerplate code within.
Post reply on HN