Simple Directmedia Layer (SDL) is the gold standard for low-level, cross-platform game development. It is an open source library that is used at the layer where one might use DirectX, so it's useful both for from-scratch development and for powering game engines. It provides abstractions for video, audio, input, and various system-provided functionality. In many cases, if you're building a cross-platform game, SDL is extremely good at helping you delete a large number of #ifdefs in your project...and entire directories full of code.
SDL is used in the Steam Client, is crucial to the Linux game development ecosystem, and has been used for various platforms in every generation of the Unreal Engine, idTech, Source Engine, etc.
A game written to use SDL might work with almost no code changes across all major desktop operating systems, mobile phones, web browsers, and even the Raspberry Pi. Nintendo shipped SDL in over 7.5 million NES and SNES Classic devices. There are SDL-based games shipping for the Nintendo Switch, the Xbox, and Google Stadia; support for PlayStation consoles is currently in development. SDL powers everything from gamejam titles built in a weekend to triple-AAA game engines, media players, emulators, and user interface libraries, across dozens of platforms and more than two decades of development.
Millions of users playing thousands of games have enjoyed SDL, probably without even knowing it. But thousands of game developers have enjoyed making those games with SDL.
When I presented a talk on SDL at the first Steam Dev Days conference ( https://youtu.be/MeMPCSqQ-34?t=1159 ), I discussed its 2D render API, calling it "the most hyped-up Super Nintendo you've ever seen."
This piece of SDL was intended to make it easy to do simple graphics in an efficient way: it was for getting sprites on the screen, with scaling and rotation, while SDL figured out how to get it onto the GPU on your behalf. This was meant to let people do simple old-school games, and also let legacy software-rendered games migrate cleanly to the GPU.
If one is making a small game, this is often all the power one needs. More complex games would use a traditional 3D API, like Direct3D or OpenGL, on top of SDL, but this causes the usual portability problems that SDL aims to prevent: the game might have multiple codepaths to do the same thing with different APIs. They might need a Direct3D renderer on Windows, OpenGL on Linux, Metal on macOS, etc.
We have resisted building a 3D graphics API into SDL because in the previous generation these APIs have been massive and ever-expanding. But this has caused developer friction, as games outgrow the 2D API, or need Just One More Feature that it can't provide. It's not uncommon for developers to build games using our 2D API and then directly talk to OpenGL to augment the 2D functionality, losing portability (and stability!) in the process.
However, the new generation of 3D APIs gives us an opportunity we've never had before: the API surface can be very small, and almost all of the power is in shaders provided by the application. The new generation has not only embraced the programmable pipeline, it has embraced the command queue and precooked rendering pipelines, so we can ignore the old state machine paradigm going forward. This is the time to add an abstract 3D API to SDL that can be small but also empower game developers for the next 20 years, the way that Direct3D and OpenGL did for the last 20.
The plan is to produce a small, C-callable API that is included with the rest of SDL. It will expose the most important pieces of modern graphics: vertex and pixel shaders, command buffers, precooked render pipelines, etc. The goal is to expose the most power possible with the smallest API, so developers aren't running into significant limits but also won't have to manage an enormous amount of complexity.
For shader distribution, we will design a simple bytecode format that can be cheaply converted to native data at runtime, so that apps don't need to cook shaders into multiple formats ahead of time, and new 3D APIs can be incorporated into existing games simply by updating SDL without a full shader recook. We know from the MoltenVK project (a Vulkan implementation on top of Metal that converts SPIR-V to Metal Shading Language source code at runtime) that this is feasible.
And the native APIs to target? The immediate choices are obvious: Direct3D 12, Vulkan, and Metal, but it's easy to implement a command queue interface on top of older Direct3D and OpenGL with some small limtations, for older systems. The current consoles all offer similar modern interfaces, too. We know from the WebGPU working group that it's possible to account for differences in APIs and adjust transparently for different coordinate systems, etc, without the application having to know about or manage these details.
The ideal outcome of this project is a game developer writing graphics code that uses modern verbs ("encode these rendering commands," "commit this command buffer") that are efficient on current hardware, but without the complexity that lower-level APIs like Vulkan require, and deploying this code with a small library they were already using anyhow, that will figure out the best way to interact with the GPU on their behalf based on what it finds on an end user's system. They ship one set of compiled shaders and, like magic, it does the right thing no matter what platform they ship it to, or what GPU API is available on that platform.
SDL itself is a robust and powerful library with 20+ years of development; this megagrant request is to fund the addition of this new 3D API to the existing library. Beyond time spent on research and sketching out the new API, we do not yet have a prototype ready, but we are confident that this project can be completed and that our body of existing work demonstrates our ability to deliver.
Круто.