# OpenGL Render Queue Design

I am currently designing the rendering system for a 2D game built in C++ and OpenGL, and am unsure about how to go about implementing a sorting procedure to maximise efficiency and minimize OpenGL texture changes. Currently my system looks something like this:

void Renderer::draw(Sprite sprite)
{
for (Batch b : m_batches) {
if (sprite.getTexture() = b.getTexture() && b.enoughRoom(sprite)) {
b.submit(sprite);
return;
}
}

m_batches.push_back(Batch(default_size, sprite.getTexture());
m_batches.top().submit(sprite);
}

void Renderer::display()
{
for (Batch b : m_batches) {
b.draw();
}
}


However, this feels like a pretty naive implementation, and what worries me is that every time I submit a sprite into a batch using b.submit(sprite), I am calling glSubBufferData(); (So say for drawing 2000 sprites, thats 2000 calls to glSubBufferData per frame which feels very slow).

What I feel would be better is to only call glSubBufferData once with all of the vertex data that would go into that buffer. How would I go about doing this? I though about giving the Renderer class a RenderQueue vector, which when sprites are submitted are pushed back into the queue, but how would I go about sorting this vector and then splitting it up into all of the different Batches, while keeping in mind that a Batch size cannot exceed a limit? (As in, I don't want too many vertices in a single VBO).

EDIT: Also, I understand that it would be very easy to implement this if I used simply one texture atlas, however I would not like that limitation and would prefer to implement a system that allows for 2 or 3 different atlases.

• You could introduce a "RenderMaterial" that captures all "Sprites/Triangles" for one "Material/Texture" and then only submit all your RenderMaterials on "endFrame". (This also allows for nice extension, e.g. shaders & renderstates) – Andreas Jan 8 '16 at 10:48