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.
Peredvizhnikov Engine: Lock-free game engine written in C++20
111–120 of 183 posts
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#112I 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…
Could you tell me if your 10 million figure includes batching or are they a loop that tries to enqueue as many items as possible?
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#113Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#114Actors 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.
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#115Actors 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.
Observation requires good logging, but this isn’t out of line for any complex system. Debugging (as in actual breakpoints in an IDE or post-mortem analysis) can be facilitated with stack tracking (this same problem occurs with async await patterns and is solved in a similar way).
The advantages and disadvantages exist, but I think it’s an extremely effective programming model for many use cases. Formal state-machine programming, that’s the worst model, unless you need it.
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#116Earlier quoted context omitted.
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/
Actually its only the PS5 that's FreeBSD based. Switch runs a completely proprietary Nintendo OS that borrows a lot from Android.
"partially Unix-like via certain components which are based on FreeBSD and Android"
https://en.wikipedia.org/wiki/Nintendo_Switch_system_softwar...
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#117I 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?
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#118It 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.
> 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.
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 entity collide with itself, without sharing position information with other actors?
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#119Earlier quoted context omitted.
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...
He's probably referring to the Desktop/laptop market. In which case windows controls like 90%.
A Game Engine targets various platforms
A "video-game" is not something exclusive to desktop/laptop windows market
Re: Peredvizhnikov Engine: Lock-free game engine written in C++20
#120I 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?