My understanding from other work with 2D games in opengl is that the key to efficiency is drawing sprites in batches, by making as few glDrawArrays() calls as possible, each call drawing a large number of sprites off a single texture.
I was surprised to find that SDL does not provide a mechanism for this. I see some questions about people making their own modifications to support this:
My question is: Am I correct about how crucial this is for efficiency? If so, why doesn’t SDL provide for this as, like, one of the very most important things you’d want in such a library? If not, is it somehow that GL drivers have gotten smarter over the last 10 years so it really doesn’t matter so much how many times you call glDrawArrays()?
(I do understand that SDL supports more than just opengl, and perhaps other underlying renderers don’t have the batching concept. But still, like for anyone using SDL for iOS and android development, seems like batching is key?)
Draws w/o batching is very expensive for videocard/cpu, but batching need an advanced art/code structure while using, so it more complex for understand then simple draw image after image
While GPUs did get a lot faster in the last 10 years, draw call count is still important (and state changes between draws as well). For desktop GPUs you can get away with a few 100 to 1000 draw calls without much of an impact (although it’s better to use batching there as well) but mobile phones are very draw call sensitive. While fully automatic batching can be very complex, I think we should at least have manual batching support in the SDL_Renderer. What I mean by manual is prepare your texture atlases outside, order your draw calls outside, but have a way to render them batched by SDL when you actually send them in correctly (same texture and render state, one draw call after the other). For more complex rendering, like storing vertex buffers with data that doesn’t change, using shaders, etc. you will still roll your own renderer since SDL is supposed to be a light weight library so we can’t expect it to do everything.
What is misleading to me is that on the SDL landing page they list all of these commercial-quality games as “made with SDL”. But I assume these games must need the efficiency of batching?? So were they made with SDL, or with a modified version of SDL that allows more direct access to the GPU?
It appears that https://github.com/grimfang4/sdl-gpu has already addressed these issues. It seems like sdl-gpu should just be included as part of the SDL library with documentation on page 1 clearly saying “you can either draw the super simple but slow way using these (regular SDL) API calls, or you can draw the slightly more complicated but must faster way using these (sdl-gpu) API calls.”
When you say “can’t expect it to do everything”, I wouldn’t consider “be able to make an actual 2D game that runs with reasonable efficiency” to be such an usual request. (see my further comment below)
Most commercial games don’t use SDL for rendering at all. SDL is mostly used as an abstraction layer for getting all the OS specific peculiarity out of the way and for that it’s perfect. Historically it was created for porting games to other platforms as fast as possible, but that was pre 3D era. It still is very useful today but not necessarily for the same uses as before.
Thanks for the additional info. It would help to have this info on the main SDL page. To naive eyes that page seems to be saying “look what you can make with SDL as your engine!”
I personally found SDL because I was looking to port some games that I wrote using Marmalade 10 years ago. I didn’t want to start from scratch with the lowest level of opengl, so it sounded to me like SDL a thin layer over opengl that took care of platform-specific differences and boilerplate code. And it basically is that, it seems, except it’s not adequate for rendering a real game just because the interface to opengl is a bit too crude. But that could be fixed by adding the sdl-gpu code (based on what I understand of that project).
Yes. You can use sdl-gpu or have SDL set up openGL for you in a portable way and use openGL calls after that, or look at other rendering libraries that work with or alongside SDL. For very simple 2D games I still think even the SDL_Renderer is enough and will be even more so if/when it gets official batching support.