I'm aiming for almost exactly the same thing; an easy-to-use 2D sprite renderer design that's also easy to tinker around with optimisations. Unfortunately I'm still in the hacking stage myself; at this instant I'm trying to port some old SDL/OpenGL initialistion code into my new library. I'm not sure myself exactly what I'm going to do. I've only briefly dabbled in what OpenGL can do, and I'd like to try using indexed vertex lists for sprite rendering.

You are further along with your design than I am with mine, but I'd just like to give you the heads up that I hope to get to the experimenting stage in a month or two and try and answer some of the things in this post myself. You might want to see what I'm doing in my GDNet+ journals around then; although I'll be more likely checking yours for ideas [smile].

Creating an efficient and general 2D renderer is a problem I've also been tackling. As OT and TZ outlined, there really is no simple solution. I'll outline my current design and hopefully that'll spark some more discussion on this topic.

Everything to be drawn is a Renderable:


Geometry describes the vertex, index, and texture data for a renderable:

Geometry writes its data directly into buffers that are subsequently passed to OpenGL via vertex arrays or vertex buffer objects. Geometry is free to write as much data as it needs into the buffers, including multiple sets of texture coordinates.

I feel there are a number of problems with this interface. It is complex to implement; a BaseGeometry wrapper makes it easier but not effortless. It's a bit of a pain that indices cannot be zero-based. The data arrays may be accidentally corrupted by rogue Geometry. Geometry may feed bogus data into the arrays that will cause the renderer to choke. Furthermore, it lacks the ability to feed supplementary data to the renderer.

RenderState describes how the Geometry should be rendered:

RenderStates are free to manipulate OpenGL state however they please.

Such a generic interface, though it captures all the possible render states that may need to be set, has a propensity to encourage duplicated state setting. For example, both Text and Sprite may set/unset identical alpha state. One idea I have to prevent this is to use CompositeRenderStates that are composed of individual RenderStates such as AlphaState or TextureState. First, renderables may easily generate appropriate state without duplicating code. Second, transitions between composite states may be reduced to only a subset of the full state.

Renderer handles, well, rendering:

Very simply, the Renderer aggregates Renderables over a frame, sorts them, then renders them in batches. Renderables are sorted by render state, primitive type, and priority. Batches of identical state and primitive are built from the sorted list. The Renderer uses a single vertex, texture coordinate, colour, and index buffer (passed to Geometry).

Currently the renderer is exceedingly primitive. Though the geometry interface cleanly supports multiple texture coordinates (and, potentially other data via getGeomParams(Buffer)) the render has no means of dealing with them. And, in fact, I'm really not sure how to handle them. How should the renderer know which geometry needs multiple coordinates? How do I set the texture coordinate pointer appropriately for only that Geometry?

Maybe the concept of render state could be expanded to include setting up multitexturing? But then how to get the vertex arrays set up correctly? How does shader data play into this? Ahhh! I'm really at a loss.

One parting thought: is there any value in emulating the DX10 model and using vertex/fragment programs for everything? We could essentially eliminate the concept of render state and replace it with that of program state. Knowing so little about this subject it's hard for me to say what would be the impact on Geometry, Renderer, or anything really... but I'd love to hear other people's thoughts.

So, there's my take on the subject. This is a really interesting topic so I hope this post will spark some more interest.

Pursuing a brief tangent, how do you feel about pre-transformed vertices versus using glTranslate/Rotate/Scale on each object individually? My intuition says that batching is ultimately superior and the CPU can afford to do a few matrix multiplications but, of course, I lack all the pieces to verify this assumption.

Right, so my idea is a Transform object (really nothing more than a fancy name for a 3x3 matrix) very much like the SDK's AffineTransform. Geometry vertices will be transformed prior to being added to the Renderer's vertex arrays. (Hmm. Not sure how this will work in code, though, if Geometry feeds data directly into a buffer. Ideas?) I have a trivial design question: is this transform a property of the Renderable or the Geometry? I suppose it depends on whether I consider Geometry to be a generic polygon in local space or something tied to a specific object on screen. I wonder what the "better" (more flexible, easier to understand, more maintainable... choose any metric) choice is?

I was initially prompted to separate the transform when I realized that my sprites and text, both simply textured quads, were using essentially duplicate geometry code. Thinking about it now, it ultimately might make more sense to factor out a Quad class that both Renderables share. Moreover, I think you're right in saying that most custom geometry (i.e., more complex than a polygon) will have a unique or more useful interpretation of a transform than could be easily represented generically.

My concern then becomes, given the classes Triangle, Quad, and Polygon, how do you factor out what is bound to be redundant transformation code? I suppose I can answer my own question and say that we only really need Polygon and if I'm desperate for specialization I can construct something like Polygon.Quad.