Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
    
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 at 10:48

Your Answer

 
discard

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

Browse other questions tagged or ask your own question.