| bio | website | |
|---|---|---|
| location | ||
| age | ||
| visits | member for | 4 months |
| seen | Jan 21 at 9:33 | |
| stats | profile views | 0 |
|
Jan 14 |
awarded | Editor |
|
Jan 14 |
revised |
High volume sprite management in entity component system added 475 characters in body |
|
Jan 14 |
awarded | Student |
|
Jan 14 |
comment |
High volume sprite management in entity component system A tilemap is fine for tiles but for entities that sit on top of the tiles, e.g a tree which may occupy 2x2 tiles, 4x4 tiles etc. how would a map or spatial partitioning be implemented on components? |
|
Jan 14 |
comment |
High volume sprite management in entity component system Thanks for the answer krzat. Each system already stores lists of compatible components. My problem lies in the fact that the system must iterate all 5000 compatible RenderableSprites components regardless of whether those RenderableSprites contain any sprites that are on screen or not. I want to reduce this iteration to the say 200 components that are actually relevant to the draw step as i believe this is the source of the performance cost. |
|
Jan 14 |
asked | High volume sprite management in entity component system |