单个或多个SDL_Renderer

Question

I'm slowly designing structure of classes involved in my "game", and I wonder if SDL_Renderer should be a common resource, synchronized across multiple threads or each different object should have its own Renderer (ex. each enemy refers to its own renderer to make its presence on the window). Any advice would be appreciated, best with an explanation.

Thanks in advance.

Answer 1

Just a single renderer

As keltar pointed out, the API is not made to be used like this. But that's not a flaw of the API. The underlying work done by the GPU is just very different from the "render this and that" calls done in the C API, so concurrency doesn't translate 1:1 like that. In a sense, the CPU is mostly just telling the GPU what to do, and telling it twice the things at once won't make it work twice as fast.

Not fast enough?

If you're writing a 2D game for any platform that's relevant today, then SDL2 should be fast enough in most cases. If your game isn't running fast enough, perhaps something else is going wrong and something on the CPU side is causing a bottleneck. Are you sure you're using hardware accelerated rendering? Perhaps some setting went wrong and it's using the software renderer as fallback - call SDL_GetCurrentVideoDriver() and chek the result to make sure that this is not the case. Other things that might bottleneck the performance are any usages of SDL_Surface. Also, loading lots of data to the GPU all the time can cause it to slow down, so make sure to not load sprites more oftne than neded. For instance, when the same monster is loaded again, then you can reuse the textures you already loaded instead of loading them again. Another example is SDL_TTF, this library is slow. Rendering some HP number for a monster is much slower than rendering the monster in the first place - there are alternatives where the glyphs are prerendered and stored as textures.

Rendering textures faster

Having said that, rendering lots of small sprites does have somewhat of an overhead and if you need to render an extreme amount of sprites, it might not be fast enough even if you are doing everything right. There are libraries such as SDL_gpu that can leverage techniques such as texture batching to increase rendering speed in some cases. You can also work directly with OpenGL, but that's what libraries like SDL_gpu do anyway. Last but not least, SDL2 supports Vulkan now and while I haven't had the opportunity to try that yet, it supposedly is much more efficient when it comes to API calls on the CPU side. So if that's your bottleneck and using Vulkan is a possibility, it may be worth a shot.

Sorry if most of this doesn't even apply to your question. Perhaps you don't actually have a bottneck/performance issue, but were just curious about how the API would be used optimally.