91–100 of 183 posts
Earlier quoted context omitted.
From the grammar, I would not assume GP is a native english speaker, much less monolingual.
I would love to hear what exactly about the grammar doesn't sound native.
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…
My benchmarks show that the price is acceptable Well, except to people who have a hard requirement that there never be this unpredictable, infrequent longer delay you mention.
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.
What is a better alternative?
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. MonoGame, mine, and others have used it, it’s battle tested.
I just can’t look at SDL code anymore and say “this is the cleanest api” for anything outside of C99.
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.
This implementation relies heavily on restartable functions in order to allow another parallel thread to pick up and continue the work of an already in progress but otherwise interrupted actor. See page three of the (excellent) design document: https://github.com/eduard-permyakov/peredvizhnikov-engine/bl...
Thus while it might not strictly be "more parallel" (same number of actors), it does seem to be able to make better use of more parallelism for completing the same set of work.
> 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...
Earlier quoted context omitted.
> 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…
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 think I'm disagreeing with you. Supporting multiple hardware configuration way back when was so much harder than doing it today.
Earlier quoted context omitted.
What is a better alternative?
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…
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.
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.
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.