wait hang on. why does ECS always use bare arrays for holding structs? that makes the bookkeeping way more difficult. wouldn't it be easier to use a simple array based hash table, so that every entity can simply store their data using their ID as the key?
that way iterating over all the values in the table is still fast and cache coherent (it's still just an array) but all the bookkeeping becomes way less complex. no more need for archetypes, just have one hash table per struct and if an entity doesn't have that component, it's as simple as just not adding it to the table
... am i missing something here? O_o i feel like i'm missing something obvious
@eniko Isn't that just to serve the cache locality purpose?
Also you may find https://github.com/SanderMertens/ecs-faq helpful, iirc it goes into this too
@eniko Well... sort of? From what I remember, the whole archetypes thing serves to group together data for specific (sets of) components, because you're usually going to iterate over "all entities that have this specific set of components" - and for optimal cache locality you want the data stored to *only* be the data you are interested in because of the limited cache size.
So if you were to store all of an entity's data in an array, instead of just its data for specific components, less entities worth of data would fit into the cache (because the data includes irrelevant stuff) and that would incur a performance penalty.
(Going off my potentially lossy memory here)
@joepie91 hmm that's a decent point. if you need multiple components then it's worse for every one beyond the first
@joepie91 yeah, i know its about cache locality. but a hash table built on a backing array would still have good cache locality