I do not know how to contribute, so I publish my patch here.
I wrote a simple autobatching for the OpenGL ES2 backend.
Perhaps this is not optimal, and someone can optimize it.
But now I can use a particle system with many calls to SDL_RenderCopyEx.
This is my old variant. New patch is compatible with SDL 2.0.8.
I look forward to your changes!
And it would be great to provide API for customizing shaders and working with vertices. For example, my dream, Spine on the SDL.
If you want, you can use my code without any references or restrictions. In my implementation, you can determine the maximum number of vertices at compile time.
Maybe it is better to move a color from the uniform to the vertex attribute?
In my games I use a particle system, and there are many particles with different colors, therefore, to avoid problems with batching, I keep the color at the vertex attribute.
I’m all over this - it’s very exciting! (maybe not the best choice of phrase).
Just built with the VisualC project (ah yes, smaller DLL as you said before - Steam must have compiled with VS).
Initial observation: I’m drawing 10000 coloured filled boxes (SDL_SetRenderDrawColor & SDL_RenderFillRect). The new build is twice as slow as the official build’s DLL? I notice SDL_RenderDrawRect calls SDL_RenderDrawRectF, but it shouldn’t make it twice as slow? And resizing a window causes all drawing to stop working. Perhaps I’m building it wrong or it’s broken in a big way? I’m happy to start submitting bugs, but just making sure this is SDL’s side and not a VisualC & me specific thing?
Edit: the halting of any rendering after window resize only happens with the Direct3D renderer. A bug introduced after 2.0.9 release.
Okay, quite concerned at the results on Windows. Just doing simple filled rects in openGL renderer in my test and without batching I’m getting 1000fps, with batching I’m getting 200fps - ouch. Even direct3d renderer gives me 800fps without, and 500fps with.
Am I missing something? Can someone supply a new DLL built with cmake for me? (so I know it’s not VisualC’s build that’s choking this). Anyone else joining me on the this batching quest?
No, I didn’t know about this, sorry. That works, thank-you!
But it’s no faster than 2.0.9 release, so was it batching in the background anyway before? With this hint it’s the same speed it was before. post 2.0.9 it’s much slower (especially opengles2) unless you turn this hint on. I can’t see an improvement.
So, I think, if you don’t activate the hint, it works as a compatibility mode not to break existing games. It draws immediately when requested.
When you activate it, every commands get grouped and it draws in one shot.
The only way I could get things to draw between pixels was to set NVIDIA’s antialiasing mode to override applications. Is this because SDL_HINT_RENDER_SCALE_QUALITY anisotropic setting is not implemented? Currently textures have either no filtering, or linear filtering, neither of which allow the texture boundaries to fall outside of pixel alignment.
That’s right, but you only need the hint if you request a specific renderer. If you call SDL_CreateRenderer() with a -1 index (and haven’t forced it with the SDL_RENDER_DRIVER hint), it’ll do batching, under the assumption that you won’t call OpenGL/Direct3D/whatever directly, since you might not have gotten any specific GPU API anyhow. If you tell SDL you need OpenGL or Direct3D or whatever, we have to assume you might call it at any time, and thus turn off batching. That being said, my testing with most renderer backends without batching is still faster than 2.0.9 due to other optimizations, but YMMV for several reasons.
It’s good practice to set the hint to allow batching anyhow, though, since an end-user might force a renderer with an environment variable, even if your app doesn’t call any lower level APIs.
(It’s also worth noting that Metal always does batching; because of the nature of its command queue, we can make guarantees that we can’t in the GL state machine. I expect a potential future Vulkan or Direct3D 12 renderer would be similar.)
In 2.1, we’ll probably remove this hint and make it so you must call SDL_RendererFlush() before touching a native API and always do batching otherwise.