151–160 of 183 posts
Earlier quoted context omitted.
Never mind that a lot of Volga boats were very single-threaded. https://www.amusingplanet.com/2021/12/belyana-russias-giant-...
You can even see the steam ships that replaced the slave in the background.
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 think what you're observing, i.e. that in many cases just use a lock and don't worry about it (or your variation) is true. But there are certain applications/situations where you can do better. Having a consumer pull out everything from the queue with one locking operation and being careful with how you signal the consumer from the producer(s), assuming there's a signal, can also make the queue more efficient/have higher throughput (e.g. you shouldn't signal for every item you put in the queue, only when it becomes non-empty).
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.)
"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.
Latency is like a chain. Every link matters.
A game engine programmer can't do a thing about the OS, but can still keep latency bounded in the code under their control.
Earlier quoted context omitted.
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.
> 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 .
Earlier quoted context omitted.
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.
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…
Earlier quoted context omitted.
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.
Also there's exactly 2 ways to get a window on Linux, and those 2 ways are common to pretty much every modern distro. Same as audio.
The engine also focuses on message passing, but from experience it's very difficult to work with (state machines are hard, especially when working with multiple downstream actors), and at the core actors are more about isolating state without locks than message passing. Swift actors did it right in my opinion, method calls instead of messages are not only easier to reason about, they give additional hints to the runtime when context may switch without involving a scheduler at all (any shared state is slow and inhibits scalability).
I actually wrote a header-only library recently (search for "coroactors" if you're interested) that implements something similar to Swift actors with C++20 coroutines, and I thought ~10 million requests/s (when uncontended) or ~1-3 million/s (when contended and depending on a scheduler) was a way too high of an overhead, especially when compared to normal method calls with shared state protected with mutexes. Coroutines tend to go viral (with more and more functions becoming "async" coroutines), and any non-trivial code base would have a lot of coroutine calls (or messages passed), and that overhead needs to be as low as possible, otherwise you'd spend more time task switching than doing useful work.