moodycamel VS entt

Other than that... if your stuff is good, that's a much better signal than a professional username. I've seen a lot of decently unprofessional usernames out there that get taken pretty seriously because of the good work behind them. My recent favorite is "moodycamel" who authored a great concurrent queue library in C++.

In c++ the moodycamel ConcurrentQueue is a good choice.

Here's a decent concurrent queue: moodycamel::ConcurrentQueue.

Lock free programming is hard, and probably harder than you think. I would not even try something like that myself. I would look for existing solutions, something like https://github.com/cameron314/concurrentqueue for example.

I needed a concurrent queue that would block when attempting to pop an empty queue, which allows the consuming thread to suspend while it's waiting for work. I found that using mutexes allowed me to develop a simple template adapter had several advantages with few drawbacks when compared to non-blocking queues: it can use a variety of containers, the code can be reviewed and verified as to its correctness (very hard to do with fancy concurrent programming that avoids mutexes), and it is only slightly slower than fancier solutions (when I benchmarked it originally, it was 4x slower than Moody Camel's concurrent queue, which to me is fine performance).

Not literatue but an example. This is a lock-free (not wait-free!) multi-producer multi-consumer queue, not a FIFO, but access patterns should be similar - if not the same: https://github.com/cameron314/concurrentqueue

If I do implement it, the most likely route I'd take is make a compiler in Clojure/clojurescript that uses Instaparse (I have a more-or-less-clojure grammar written that I was tinkering with) and generate C++ code that uses Immer for its data structures and Zug for transducers and what my not-quite-clojure would support would be heavily dependent on what the C++ code and libraries I use can do. I'd use Taskflow to implement a core.async style system (not sure how to implement channels, maybe this but I'm unsure if its a good fit, but I also haven't looked). I would ultimately want to be able to interact with C++ code, so having some way to call C++ classes (even templated ones) would be a must. I'm unsure if I would just copy (and extend as needed) Clojure's host interop functionality or not. I had toyed with the idea that you can define the native types (including templates) as part of the type annotations and then the user-level code basically just looks like a normal function. But I didn't take it very far yet, haven't had the time. The reason I'd take this approach is that I'm writing a good bit of C++ again and I'd love to do that in this not-quite-clojure language, if I did make it. A bunch of languages, like Haxe and Nim compile to C or C++, so I think its a perfectly reasonable approach, and if interop works well enough, then just like Clojure was able to leverage the Java ecosystem, not-quite-clojure could be bootstrapped by leveraging the C++ ecosystem. But its mostly just a vague dream right now.

I would recommend https://github.com/cameron314/concurrentqueue as it's very battle tested and fast.

This was explicitly considered for spdlog (using the moodycamel::ConcurrentQueue) but rejected for the above reason. I'm not involved in the development of spdlog but personally I agree, for me it's important that log output is not all mixed up.

EnTT is a popular alternative to flecs for C++, which has different performance/memory characteristics.

https://pastebin.com/VPypiitk This is a very small experiment i did to learn the metaprogramming features. its an ECS library using the same model as entt (https://github.com/skypjack/entt). In 200 lines or so it does the equivalent of a few thousand lines of template heavy Cpp while compiling instantly and generating good debug code.

Some walkthrough:

Line 8 declares a SparseSet type as a fairly typical template. its just a struct with arrays of type T inside. Next lines implement getters/setters for this data structure

Line 46 Base_Registry things get interesting. This is a struct that holds a bunch of SparseSet of different types, and providers getters/setters for them by type. It uses code generation to do this. The initial #insert at the start of the class injects codegen that creates structure members from the type list the struct gets on its declaration. Note also how type-lists are a native structure in the lang, no need for variadics.

Line 99 i decide to do variadic style tail templates anyway for fun. I implement a function that takes a typelist and returns the tail, and the struct is created through recursion as one would do in cpp. Getters and setters for the View struct are also implemented through recursion

Line 143 has the for expansion. This is how you overload the for loop functionality to create custom iterators.

The rest of the code is just some basic test code that runs the thing.

Since we wanted a common game simulation that would be on both the server and the client we looked into a few libraries that would fit our ECS needs. It was decided we were going to write this common part of our game in C++, but rust was considered. C++ was a familiar language for us so naturally EnTT and flecs came up right away. I had used EnTT before, writing some small demo projects, so our choice was made based on familiarity. In order to integrate with Unity we created a small C interface to communicate between our simulation code and Unity’s C#. Here’s close to what it looked like. I removed some parts for brevity sake.

Are you sure you don't want to use a C++ package manager? Libtcod is on Vcpkg and with that setup you could add the fmt library or EnTT. fmt fixes C++'s string handling and EnTT fixes everything wrong with the entities of the previous tutorials.

There's also a performance question. While we can now use Blueprint nativization to convert Blueprints to C++ the result will be a fairly naive version, fast enough for most purposes but not if you're trying to push every bit of performance. This is where you're looking at making sure you're hitting things such as using the CPU cache as well as possible for an ECS system (Look at ENTT or Flecs if you want to see what they're about and why you'd want one), or a system needing to process massive amounts of data quickly such as the Voxel Plugin.

For a modern engine you’re probably best looking at Unity’s DOTS. You may also want to check out some of the different open source ECS libraries such as flecs and EnTT are two popular ones for C++, but there’s lots of them. Largely you’ll see lots of different approaches taken, all with their own pros and cons. Not all of them will be performant (some focus more on the design benefits) while others will be optimised for certain use cases. What you should prioritise will depend on your specific needs.

You can think of DynaMix as combining one of these libraries with an ECS like entt(https://github.com/skypjack/entt)