With a basic plan for the component pools laid out here, then the issue becomes a basic implementation. Thus, here, is an overview of an implementation following the requirements laid out in the last post.
So, with the organization and distribution of the EntityIDs, the next order of business is to be able to assign data to these objects, so that they can be a part of and interact in systems and with each other. This is accomplished by assigning different components, and these components will reside in the assembled component pools.
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.
Oftentimes, when a large new project lift off the ground, a backbone architechture needs to be selected/devised in order to serve the needs, current and future, of that project. That includes the requirements of being easy to maintain, modify, and expand when necessary, encompassing new requirements as they are added.
To make setup/teardown of Vulkan graphics pipelines easier, I have created a dtemplate type that contains all the required groundwork to build new pipelines. These pipelines however, are static, unchanging and use the same set of shader modules. Perfect for smaller, test programs.