Replies: 1 comment
-
|
I do not have so much insight into this, but what you describe is in the ECS considered as a big component. bitECS implements this well by utilizing Structure of Arrays, so a component can, in theory, be as big as you want. Of course, when you begin to access many arrays at once in a loop, the benefit of the cache will disappear, since, as you say, there will be too much data to store. An ECS guru would probably say, access only a small amount of data in every loop, or as they would say, "use small components". Consider my example, which looks very much like yours! Maybe this is a very bad example of ECS since I even put the "same data" in RTCAction and RTCStatus, for example, targetX, targetY, targetZ... The reason I do this is that I want to differentiate between what the user requests and what the server returns. I suppose another way would be to simply make two entities, one that shows what you want to do, and another to tell what the server gives back. So yeah, just saying, small components are difficult to do! You want to keep packing more data as you feel might be needed. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
So I'm starting to have that kind of code
And I'm thinking this might defeat the benefits of ECS as this code is always switching between array access (x, y, rotation, depth, ..). I've read that starting with 1k f32 array memory chunks are getting too large to fit in CPU L1 cache. So should I monitor entities number and write one loop per array access if it exceeds a certain number of entities?
Beta Was this translation helpful? Give feedback.
All reactions