With the main design out of the way, come the actual work of implementing a system that is not only functional, but is extremely fast for what we need it to do. To do so requires custom sorting, and movement operations for the data to keep time managable.
So, with the organization and distribution of object IDs complete, the more interesting work comes with having to quickly, and efficiently storing the associated sets of data so that any/all data can be quickly accessed and/or modified for possibly an incredible number of times, each pass, for a possibly realtime system, but not only that, these objects may be shared across multiple threads, and as such, data integrity must be a major consideration.
So, the largest part of any large entity-based system is, of course, the objects themselves, whether they represent sounds, visual content, npcs, inventory items, models, view screens, interactable buttons, or any combination of the above. Many engines will typically abstract these objects into predefined classes, but there are issues where these become fairly inflexible, even if they are quick to process because of their static nature. By making entity objects just disparate pieces of data tied together by a unifying object ID, we might be able to have a more capable, flexible, and extendable system.
So, while the original thread pool did the job, there was a little room for improvement that I devised, and that was to do something useful with the idle async threads. Not only that, but purging the mutexes and replacing with faster atomic flag helps reduce downtime, and modifying the thread functions reducing spurious wakeups.
One of the most valuable basic types in computer science is the floating point type. The float is that allows for a massive range of storable values, at the cost of some precision after the value becomes large enough, due to the fact that floats can only store ~7.2 decimal digits. Thus, if we wish to keep a certain fixed amount or precision, we need to either put coded limits around the use of particular floats, or just create our own fixed point type.
A developer console is used for two typical purposes. The first is to output certain basic text-based messages from the program to possible places for people to read said messages. The second, is to allow a developer in input text and have certain basic commands executed by the program. It's basically like the OS command line, but internal to the program.