There’s a very simple way to implement batching under the hood that would coalesce all draw calls with the same source texture, using a multimap. Unfortunately, this very simple method is also likely to introduce errors, as it could conceivably reorder draw calls and cause sprites to be drawn on top of something they were supposed to be rendered underneath of.
A slightly more complicated method would be to introduce a “begin layer / end layer” API that uses a multimap and lets the developer do all the rendering they need one layer at a time, with the responsibility being on them to render the layers bottom-to-top.
Not that @icculus needs our advice on this, but simpler and easier would be to put all polygons with the same texture into an array, and when the array is full or something else happens that would necessitate flushing it, submit that array as a VBO/VAO for drawing. Preserves draw order etc
What I did was create my own content manager system but for glyphs.
Basically 3 structs. Glyph, glyphset and Fontmanager.
The Glyph struct stores the individual glyph.
glyphset keeps all the glyphs in a single set of a font. Such as if you had X font, size, bold or italic… one that differs slightly can be stored in a different set.
The fontmanger is responsible for loading and storing the sets and deleting them at the end of the program.
When it comes to performance glyphs are each individual texture. So if you just display them the way they appear in a line you will take a performance hit. You will get improved performance by stepping through them alphabetically. (Batching)
There is another alternative rather than storing the glyphs as textures you could store them as surfaces. this has a number of advantages. You can easily manipulate the color of them. You could render copy them yourself to a surface and then display the single surface to screen. In my case I would do that off on another thread.
opengl can give you an advantage when it comes to performance. You have access to instancing not just batching. It is also more friendly to multithreading. SDL2 appears from what I can tell to have some threading involved in its renderer system. you can run into issues were threads can conflict with that thread and actually slow stuff down.
To give you an idea how much batching can make a difference. I sent 40,000 circles bouncing across my screen. 5 different colors. Using batching I got over 60 fps. Swap back forth between circles instead of batching and it drops to 25fps. Even when I batched at 1000 circles it still gave me 60fps.
More or less, this is what I went with; when we hit a draw command, we just look ahead and mush all the draw commands using the same texture into a single glDrawArrays() call.
The work-in-progress patch is here:
This has a ways to go, but initial testing looks promising!