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'm trying to wrap my head around how batching is done in a 2D sprite-based game. My understanding is I'd get the vertices that represent each sprite I want to draw and stuff them all into a single mesh. That way I'd only need a single draw call to render everything.

Does this apply when the sprites I render are different between frames, or when some sprites are moving? Because it sounds like I'd then have to recreate my batch mesh each frame, using either glDrawArrays/glDrawElements or a streaming VBO I assume. Does this sound correct?

share|improve this question
Sprite batching is simply reducing the overhead by transmitting the data all at once, not to reduce memory needed or something. So making everything in a CPU array and then uploading it is fine. – API-Beast Dec 2 '12 at 21:40
You can update a VBO if only parts of it have changed but I find that the overhead of checking what has changed often doesn't outweigh recreating the VBO entirely. – Roy T. Dec 2 '12 at 21:56
up vote 6 down vote accepted

Yes, that's correct. Take all sprites that use the same material (share the same atlas) and draw them using a single dynamic:/steaming VBO.

If you have static sprites, it may be more efficient to put all those in one VBO, and the dynamic ones in another. If you have a large number of sprites, it may also be advantageous to use more than one VBO and split your batches up to reduce the size and amount of geometry you send in each draw call.

As with all optimizations, profile and check what is faster rather than assuming or taking advice off the Internet at face value.

share|improve this answer
Would +2 for the last paragraph, if it would let me. – Trevor Powell Dec 2 '12 at 23:29
Regarding dynamic VBO usage, it sometimes gives people the heebeegeebies to think that they need to resend the data each frame and they can easily fall into the trap of only resending things that change, which leads to overly complex code and lots of tiny updates (which GPUs hate). Remember that in the days before VBOs this was always done for everything anyway, and things ran well enough then - it's not a problem; slower than having all-static data for sure, but not that much slower. – MFAH Dec 2 '12 at 23:43
Thank you. The way I've drawn sprites in the past was having a single static VBO representing a 1x1 quad that gets redrawn for each sprite, the MVP matrix and texture parameters set appropriately. I was interested how batching worked exactly to see if it'd be a technique worth switching to. – Aaron Dec 3 '12 at 22:12
You actually can do that efficiently using geometry instancing, but that's a more advanced technique and requires using a larger version of GL/D3D. In that case though you're still generating a dynamic buffer every frame with all the matrices and texture coords for each sprite; only the geometry buffer would be static. – Sean Middleditch Dec 3 '12 at 22:34

Your Answer


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.