How did they managed to pull this off so quickly? Given how long WebGPU native is in development and still not finalized, you would think it will take SDL GPU API even longer because it supports more platforms.
The reason WebGPU took so long was that they decided to write their own shading language instead of using SPIR-V. SDL didn't make that mistake, you bring your own shader compilers and translation tools.
There is a sister project for a cross-platform shading language [1] and another for translating existing ones between each other [2] , but they get done when they get done, and the rest of the API doesn't have to wait for them.
WebGPU was made by a committee of vendors and language-lawyers (standards-lawyers?) with politics and bureaucracy, and it shows. SDL_GPU is made by game developers who value pragmatism above all (and often are looked down upon from the ivory tower because of that).
Yeah, legal strikes again. Unfortunately SPIR-V was never going to be an option for WebGPU, because Apple refuses to use any Khronos projects due to a confidential legal dispute between them.[0] If WebGPU used SPIR-V, it just wouldn't be available in Safari.
See also: Not supporting Vulkan or OpenXR at all, using USD instead of glTF for AR content even though it's less well suited for the task, etc. (Well, they probably don't mind that it helps maintain the walled garden either... There's more than one reason for everything)
Dean Jackson
Myles C. Maxfield
Robin Morisset
Maciej Stachowiak
Saam Barati
## Google
Austin Eng
Corentin Wallez
Dan Sinclair
David Neto
James Darpinian
Kai Ninomiya
Ken Russell
Shrek Shao
Ryan Harrison
## Intel
Yunchao He
## Mozilla
Dzmitry Malyshau
## W3C
François Daoust
Dominique Hazael-Massieux
## Timo de Kort [sic?]
———
I get that Apple/Google have significantly more resources than most organizations on the planet but if these demographics are representative of other (web) standards committees that’s depressing.
I don't think that's accurate. Creating a shading language is obviously a huge effort, but there were already years of effort put into WebGPU as well as implementations/games building on top of the work-in-progress specification before the shading language decision was made (implementations at the time accepted SPIR-V).
The PoC was made in 2016, the work started in 2017, but the first spec draft was released on 18 May 2021. [1] This first draft already contained references to WGSL. There is no reference to SPIR-V.
Why did it take this long to release the first draft? Compare it to SDL_GPU timeline, start to finish in 6 months. Well, because the yak shaving on WGSL had already begun, and was eating up all the time.
Sure, but that proves my point. They took so long to decide upon the shading language that implementations had to erect a separate scaffolding just to be able to test things out.
Scaffolding wasn’t a problem at all. Both used SPIRV-Cross for shader conversions at the time and focused on implementing the rest of the API. The shading language barely matters to the rest of the implementation. You can still use SPIR-V with wgpu on its Vulkan backend today for example.
The core contributors of the SDL3 GPU project have experience with two cross-platform (PC + consoles) GPU abstraction layers, FNA3D and Refresh, which provided a lot of knowledge and existing open source code to use as a springboard to assemble this quickly with high quality.
Also tbf, the WebGPU peeps did a lot of investigations for what is the actual set of common and web-safe features across D3D, Vulkan and Metal, and all those investigation results are in the open.
In that sense the WebGPU project is an extremely valuable resource for other wrapper APIs, and saves those other APIs a ton of time.
Yeah. SDL went the path of "wrap native APIs". WebGPU went the path of "exactly what level of floating point precision can we guarantee across all APIs" along with "how do we prevent absolutely all invalid behavior at runtime, e.g. out of bounds accesses in shaders, non-dynamically uniform control flow at invalid times, indirect draws that bypass the given limits, preventing too-large shaders that would kill shader compilers, etc".
WebGPU spends a _lot_ of time investigating buggy driver behavior and trying to make things spec-conformant across a lot of disparate and frankly janky platforms. There's a big difference between writing an RHI, and writing a _spec_.
"No prototypes. Just make the game. Polish as you go. Don't depend on polish happening later. Always maintain constantly shippable code." - John Romero
I think one of the biggest problems indie game devs have is putting a lot of focus into art and polish without actually working out whether the game is fun to play. The dev gets to make enjoyable incremental progress without having to confront the difficult questions about whether the game is actually workable. Some games can get by purely on story and art, but in the vast majority of cases I think solo devs would be best served by making an absolutely minimal gameplay prototype and making it fun before thinking at all about polish.
This is why it’s good to intentionally go between the micro and macro and define some design goals or pillars. The latter give you a razor by which to judge the game and the former stops you getting stuck in the weeds.
I broadly agree with the Romero quote, getting the game playable as quickly as possible and keeping it playable is easily the most effective way of crafting a game because it enables you to routinely playtest and understand your progress. A key element of that is making the game legible and for that you do need to spend some time on “polish” because it’s an intractable element of the whole.
> keeping it playable is easily the most effective way of crafting a game because it enables you to routinely playtest and understand your progress.
Obviously.
> A key element of that is making the game legible and for that you do need to spend some time on “polish” because it’s an intractable element of the whole.
What does "legible" mean? Polishing means making something production-ready. A polished feature contains (ideally) no known bugs, has been thoroughly tested, gone through several UX iterations and brought up to a release standard.
That's not necessary for playtesting and improving the game. Unless you're done with all core game mechanics, you shouldn't be polishing.
Legible means clear enough to be understandable and polish can be a clear part of that including selling the game feel. It’s a pretty classic move to under-appreciate how much feedback from a game players need to understand it.
Your definition of polish is much narrower than mine and I fundamentally disagree with you on the value of polishing during development through bitter experience.
1. Modern C++ is obviously a huge topic but if I had to describe it in one sentence I'd go for "use smart pointers and containers instead of raw pointers and raw arrays" or "c++ is more than c with classes". If you are completely new to C++ I would recommend "Professional C++" 4th or 5th edition by Marc Gregoire. After that read everything by Scott Meyers and Bjarne Stroustrup you can get (released after 2011).
2. You could use Bazel. Also look into CMake, it's an industry standard, so to speak, and will let you generate build files for almost any kind of build system including Makefiles.
3. I don't use any but some people have success with vcpkg.
4. Clangd is a good choice.
5. A quick one that works is VSCode + clangd and CMake extensions. Clangd will let you format, lint and do some basic static code analysis. Installing clangd extension will install clangd automatically. Or, if you are on Windows, "Visual Studio: Community edition" is even easier to start with right away.
