Designing generic render/graphics component in C++?

Question

I'm trying to learn more about Component Entity systems. So I decided to write a Tetris clone. I'm using the "style" of component-entity system where the Entity is just a bag of Components, the Components are just data, a Node is a set of Components needed to accomplish something, and a System is a set of methods that operates on a Node. All of my components inherit from a basic IComponent interface.

I'm trying to figure out how to design the Render/Graphics/Drawable Components. Originally, I was going to use SFML, and everything was going to be good. However, as this is an experimental system, I got the idea of being able to change out the render library at will. I thought that since the Rendering would be fairly componentized, this should be doable. However, I'm having problems figuring out how I would design a common Interface for the different types of Render Components. Should I be using C++ Template types?

It seems that having the RenderComponent somehow return it's own mesh/sprite/whatever to the RenderSystem would be the simplest, but would be difficult to generalize. However, letting the RenderComponent just hold on to data about what it would render would make it hard to re-use this component for different renderable objects (background, falling piece, field of already fallen blocks, etc).

I realize this is fairly over-engineered for a regular Tetris clone, but I'm trying to learn about component entity systems and making interchangeable components. It's just that rendering seems to be the hardest to split out for me.

Answer 1

Templates are not the answer, no.

The first thing to keep in mind is that your Drawable components will generally just be data components. For instance, in a simpler 2.5D game I have right now, my DrawableComponet has the following broad subclasses:

• SpriteDrawableComponent
• ParticleEmitterComponent
• FluidComponent
• StaticMeshComponent

All these components do is hold data and state. All of the actual logic for rendering is encapsulated entirely by the graphics system.

The graphics system contains a list of these drawable components in a data structure optimized for rendering and batching of the draw calls. In my example, the graphics system itself is still actually fully abstracted from the low-level graphics API, and deals with more general purpose rendering concepts. It knows how to ask the graphics API wrapper to create textures, create buffers, set rendering state, load shader packages, and submit geometry to the GPU.

The graphics API wrapper is made of a smaller number of abstract interfaces. There are interfaces for the various types of GPU resources (vertex buffers, textures, shader programs, vertex attrib layouts, and state objects). The implementation of the API then knows how to map those to whichever API is in use (OpenGL 3.3, GL|ES 2.0, and D3D11, for example). The only game-specific code that we need to rewrite for each API then becomes the shaders, and only because Cg outright doesn't support GL|ES shaders.

tl;dr version:

• Components hold data.
• Rendering system manages scene state and rendering.
• Graphics wrapper deals with portability between platform APIs.