I'm working on an entity-component-system based 2.5d game. That is, entities are groups of components that are processed by systems. I am having a hard time seeing how a sprite rendering system, that targets entities with a "RenderableSprites" component, can effectively manage components when processing so that only sprites that are on screen are iterated and subsequently drawn. I can see various solutions with LINQ etc. but they all require iteration through the collection of components whether explicit or not.
What is the common practice to deal with this problem, even if not in the paradigm of entity component systems?
To solve this problem with my tile based "floor" entity, it was best to group the floor tiles into one entity whereas before they were separate. This allows indexing of tiles by position in a tilemap so that every update step (to be later limited to updates where camera movement is detected), tiles are methodically selected rather than filtered via iteration and propagated to the "RenderableSprites" component, hence tiles that are not on screen are not processed in the draw step.
I am now adding scenery entities, but it doesn't scale particularly well when each tree is a seperate entity. Any suggestions as to whether scenery should be grouped into one entity? This seems to defeat the point of an entity component system and my spidey senses tell me this will lead to difficulty calculating collision etc.
Any feedback much appreciated! I am working in XNA but I don't consider this a very language specific question.
To anyone interested: I'm in the processing of working around this; I am constructing an entity manager storing entities by ID, something I should have done earlier. This will allow me to maintain some spatial indexes against entity IDs that the sprite renderer can reference before selecting which entities to process from the manager. This is as opposed to each System holding concrete references to its target components. I will maybe post some code when I'm done.