>>102733773
>https://loglog.games/blog/leaving-rust-gamedev/#ecs-solves-the-wrong-kind-problem
I see so the idea is to use something like
struct entity { u32 id; u32 generation; }
Then you can have a normal block of memory with elements of the form (u32 generation void* data) with some stride stored in the array header. You can very easily set this up at compile or runtime depending on the use. Components are stored in arrays. To check if you have a component, simply check if the generation between the entity and the data at index "id" matches.
That is much better than what I was thinking. Because you only access one array to simultaneously check for a component and then grab the component if it exists.
I will say though, that this setup doesn't solve the problem anon mentioned earlier, with transform trees. But maybe a different perspective will be helpful. This just a stream of consciousness post, so maybe my ideas are bad kek.
I think a component pool should generically refer to any data structure that allows you to map entities of the form above using some kind of data structure that follows certain rules
struct ecs_datastruct
{
elements of data structure: (u32 generation, void* data)
u64 stride;
}
So rather than using one data structure that fits every scenario, ideally you should be writing data structures that follow a certain set of guidelines. For example, if you have a hierarchy of transforms, use a tree. The component pools shouldn't be required to have the same underlying data structure. I think that may be the root of the problem with ecs.
I guess you can possibly make a library that allows you to hook in custom function pointers for insertion, removal, allocation, and deallocation, and the relevant data structure.