So this is a long way off–design hasn’t even started yet–but I’ve got an Epic MegaGrant to add a 3D rendering API to SDL.
The long-winded high-level whats and whys of it are explained here.
I’ll be giving more concrete details later, but the basic plan is:
- The basic SDL API looks like other next-gen APIs (Metal, Direct3D 12, Vulkan)…command queues and precooked state objects, not immediate state machines like OpenGL and older Direct3D. This makes the C-callable API pretty compact, because all the power is going to be in…
- …shaders. We don’t know what this will look like yet, but the intention is for you to use the same bytecode shader on everything and let SDL figure out how to make it work with the GPU. I’m trying to decide if there should be some ability to use shader source code at runtime, too, but this may or may not happen.
- There will be one coordinate system and SDL will manage the details for various backends if things need to be flipped, etc.
- This will work like all the other SDL subsystems: it will pick the best way to get this done based on what it finds on the end-user’s system. If they are on an iPhone or Mac, that’ll likely be Metal, on Windows 11 it will be Direct3D 12, Vulkan on Linux, etc.
- Ideally we will be throwing away most (but not all) of the 2D rendering API backends, and replacing them with one that talks to this new API behind the scenes. The existing 2D API is not being deprecated, because it’s still extremely useful for certain types of games, and getting older games off the CPU and onto the GPU, etc. It’s likely there will be hooks into the new API, like how you can ask the 2D renderer for a GL texture or a Metal command buffer, in case you mostly want simple 2D but want to add on top of that (and as a benefit, you will no longer have to write to a specific low-level API to make this work).
Here are some things that are not part of the plan:
- A software renderer. It’s just not practical with shaders.
- Older 3D API backends. If we are lucky, we might get support for very new OpenGL, but the idea is this is going to map to the new philosophies and features of next-gen APIs, and bending over backwards to make (say) OpenGL 1.1 work is just not likely to happen. Which is to say, you should expect this API to fail to init if you have an egregiously old system, or try to run it over Windows Remote Desktop or whatever.
- Letting people mix and mingle between the new API and the underlying native API. The primary need for this in the 2D API was to use OpenGL magic directly on top of other 2D rendering, but we’re hoping those limitations won’t exist to need bypassing with the new API. Letting people hook in to OpenGL directly caused a lot of confusion, complexity, and special-case API additions to support it. Not to mention you were in trouble if the renderer API one day started supporting Vulkan instead.
- There are parts of the next gen things we aren’t adding right now because it feels like biting off more than we can chew: compute shaders, ray tracing, etc. These things might be added later (AND ALSO MIGHT NOT), but for a first cut, I believe this will be a quantum leap forward in the rendering functionality we currently offer, more than enough for both small indie games and all but perhaps the most bleeding edge triple-A titles.
- An optimizing shader compiler. I do not intend to turn SDL into a compiler project or import a dependency on LLVM. I expect to lose some performance to this, but not a significant amount. It’s not impossible that an external project that offers an offline, optimizing compiler, could arrive at some point.
You might have questions, and I think it’s important to say that in these early times the answers will change as we find out parts of this plan are a bad idea and I pivot on various details. But I can provide my best-laid plans at the current moment for any questions.