Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I have an entity component system and a 2D rendering engine. Because I have a lot of repeating sprites (the entities are non-animated, the background is tile based) I would really like to use batch rendering to reduce calls to the drawing routine. What would be the best way to integrate this with an engtity system?

I thought about creating and populating the sprite batche every frame update, but that will probably be very slow. A better way would be to add a reference to an entity's quad to the sprite batch at initialization, but that would mean that the entity factory has to be aware of the Rendering System or that the sprite batch has to be a component of some Cache entity. One case violates encapsulation pretty heavily, while the other forces a non-game object entity in the entity system, which I am not sure I like a lot.

As for engine, I am using Love2D (Love2D website) and FEZ ( FEZ website) as entity system(so everything is in Lua). I am more interested in a generic pattern of how to properly implement that rather than a language/library specific solution.

Thanks in advance!

share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

that would mean that the entity factory has to be aware of the Rendering System

If your entity factory function has to create objects for/from the rendering system, the obviously your entity factory function needs to create objects for/from the rendering system. There's no avoiding that; it's a part of what you need to do.

A component system is not supposed to eliminate dependencies. It's supposed to minimize them and focus them on the necessary dependencies, not the unimportant ones.

Users of your entity class shouldn't need to specifically know about the rendering system, unless they are dealing with the visual representation of an entity. Users of your entity creation functions may need to because, as code responsible for building entities, they need to know about all of the things that entities depend on. Thus, the dependency is focused on where it is needed.

Doing this doesn't violate encapsulation; the entity creation process needs to create rendering system objects (as well as possibly sound objects and other such things). It needs to know about these things in order to do its job.

To create an entity, the entity factory code must either be given some kind of rendering system object to create the visual representation from, or it must go out and find it. One of these things has to happen. You can create abstraction after abstraction, and it still will need to happen somewhere. If an entity needs a visual representation, then some piece of code somewhere is going to have to know about both entities and visual representations.

share|improve this answer
    
By rendering system I am referring to the rendering system within the Entity System pattern (not the actual renderer), which is not supposed to be used or aware of anything besides the entity manager, cache and the controller manager(that calls its update function). Sorry if I wasn't clear. What you are describing makes sense though, and I think that if I use just one more level of abstraction (a sprite factory as suggested in the answer below) I will achieve good separation and acceptable dependency list at the same time. –  Kiril Sep 16 '12 at 14:40
add comment

Make a sprite factory (preferably inside another rendering-related structure, like the renderer). It can internally be capable of ordering and grouping sprite data as required for batching.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.