Are Components held contiguously in memory?

[puradox]

I know in #23 you addressed that you made a simple library called tac to address the issue of Components not being allocated contiguously in memory. I saw that #23 was addressed but closed yet. So have you already implemented this contiguous storage container library in anax?

[miguelmartin75]

No, not as of yet. I am working on it in the develop branch. I will still have to write some benchmarks (perhaps with a written game that is quite intensive on the CPU) to see how much of a performance improvement there is (i.e. if there is any improvement at all, or if what I've implemented is worse than using new/delete).

I'm planning to just use a std::deque as the underlying container, which means each component type aren't strictly in memory contiguously, but for the most part they will be. This also means that references to components will not be invalidated when a resize is invoked (from a push/emplace_back), unlike std::vector.

My only major concern will be holes within each container, e.g. when you kill an entity or if there entity X doesn't have component Y. Since the index of the component will be the entity's ID.

[puradox]

For remedying the possible holes within each container, have you considered using a std::set to keep a collection of the removed entities' ID? Then the next time you create an entity from a world, you could fill in the holes with the help of the std::set.

However, there would be increased memory usage in exchange for keeping track of such things. I completely agree that benchmarks are needed to see if there is any performance improvement.