SDL gets an Epic MegaGrant to work on next-gen Vulkan API
patreon.com
patreon.com
The official documentation [1] is just an API reference. There's no official tutorial or getting started guide that gives enough context to a beginner. There's just a bunch of links to (mostly outdated) third-party tutorials and books and some articles talking about specific parts of the library, but nothing official that serves as a foundation to a begginer.
The SDL_* subprojects ... I'm not sure if they're official SDL subprojects, third party projects that share the name, or something in between. The homepages (e.g. [2]) of these subprojects are totally different from the main project's, and their documentation is also just a listing of every function, without a general context.
Maybe for someone who already is a professional game developer, SDL is just perfect, but for a begginer (like me at the time), it's just obtuse.
It's not SDL's fault beginners have poorly defined/uninformed expectations.
But you're right about the documentation being kind of a mess. The SDL1.2 vs SDL2 differences can be annoying and for a beginner just figuring out what version the example/tutorial code they're looking at relates to can be challenging.
It might not be their fault but I'd still say they're probably in the best position to correct it.
From what I saw the primary cause was beginner game programming tutorials on the web, outside the SDL project, created by volunteers, judging by the code quality, often beginners themselves. The lazyfoo ones were especially popular back when I was involved.
These tutorials would go immediately to creating a main.c with an SDL dependency, before even discussing game engine architecture or frankly anything at all. So you have a total noob who likely doesn't know anything about C let alone game development, being faced with their first C listing and it's immediately mentioning SDL junk for creating a window and this stuff called an event loop.
Of course the newbie is lost, most the time they can't even get it to compile. The tutorial is some random abandoned long-forgotten thing on the web, with zero support available. So where do they go? SDL of course! It's the only thing on their radar at this point, and while barely on life support, there's still something resembling a community in #SDL, more recently I think they shifted to slack or something so maybe it's improving.
SDL isn't in the business of teaching to build game engines. Just because awful game programming tutorials on the web tend to start with SDL because it's the platform abstraction so you initialize it first, doesn't mean SDL should take on that role, which seems to be what you're implying they're best positioned to do. There's already insufficient resources to maintain the API docs and fix bugs as-is. If you're interested in volunteering for the job, Ryan Gordon is the man to reach out to.
Once you know how to open a window, poll for events (maybe even create custom events and use the event system for messaging or signals), load a texture from a file and make sprites, and maybe basic AABB collision detection with rects, you know most of what SDL is useful for. Everything else is "code the rest of the f'ing owl" territory, which is outside SDL's purview.
That being said, I think what throws a lot of people off is that SDL isn't really the best tool for someone focused on just writing a game.
To me it's a toolkit to make your engine cross-platform, whereas a lot of people are expecting an engine.
I'm still partial to SDL-1.2. I think SDL-2.0 suffers from a lot of scope creep, such as multiple windows, menus, and trying to constitute a more general graphics library while complicating things for people doing basic framebuffer stuff. I'm slowing coming around to think that for a lot of people, it makes sense to have such a thing, though - particularly, hardware accelerated basic 2D graphics without dropping down to increasingly obsolescent OpenGL code. It's entirely laziness stopping me from converting my remaining SDL-1.2 code to SDL-2 at this point.
"Need more power? Use OpenGL."
"Need more power? Write a shader."
?But I'm not sure this SDL effort is a good thing. SDL has always been behind on fixing its bug backlog for the hard things it does well, like supporting so many game controllers and audio backends, supporting iOS and Android, etc., and other efforts at an easier to use 3D API that better abstracts different vendor GPUs have been underway for some time:
- WebGPU
- Godot's shading language
I have always loved that SDL separates its libraries so you don't have to use what you don't need: if you don't need an audio mixer don't include SDL_mixer, etc. Hopefully those of us that don't need SDL 3D will still be able to skip building and including it, avoiding bringing in all the bugs, bloat, and complexity therein.
I interpreted it quite differently, the author writes:
> there's just less knobs in general. Almost all the magic you want to do is done with shaders. Since these GPU APIs have a little programming language of their own, the GPU API itself doesn't have to be super powerful. It can be small, designed to exactly how one would control the hardware efficiently, and the programmer has tons of freedom, because they can get buck-wild in a shader with almost no limits.
Which to me implies the Vulkan API is so simple, and close to metal, that it doesn't differ between implementations.
As someone with 20 years 3D programming experience including paid work in DirectX and OpenGL ES 2.0, I attempted vulkantutorial.com but gave up because it is too hard. It really is 1000 lines of C/C++ to even get a flat shaded triangle on screen. Vulkan has validation layers to help with writing conformant portable code, but the validation layers are written by your GPU manufacturer and so you can get things that pass on an Intel GPU but fail on nVidia. If you've ever tried porting your "portable" ISO C++ code that works with GCC over to Visual C++ and dealt with 1000s of lines of compiler errors it's kinda the same thing. Vulkan has shaders that precompile to "portable" bytecode but I also noticed that the time delay of loading these "precompiled" bytecode shaders was instant on one Intel GPU but took about 5 seconds on an nVidia GPU. The nVidia driver then cached the results (I know not where) so that subsequent runs were faster, but the cache can be invalidated by either a driver update or a shader update, so your game level loader will need an "ifShaderLoadingSlowerThanMolasses() {...}" code path to deal with your users experiencing slow load times after a video card driver update, etc.
Summary: in ages past it was possible for mere mortals to write visualizations and simple games directly in OpenGL/DirectX, but with Vulkan most of us will need a middleware layer on top of it to get anything done within a deadline. If you want an open source portable solution I instead recommend Godot. If you want to make a 3D game that makes millions of dollars with less than 3 years of development and can deploy to Nintendos and Playstations with a button click I recommend Unreal Engine or Unity.
It's funny how 1980s Nintendo cartridges loaded instantly but now that we have hardware at least 10 million times faster we have long load times for games.
If security is an issue (can a shaders be dangerous?) you could wait until you have X copies of the same hash and verify that they all have compiled to the same code before adding it to the online cache.
Developers could even pre-compute such shaders for popular GPUs that they have access to.
And WGSL seems to be going the way of Vulkan in what concerns shading languages, taking the fun out of playing around with WebGPU.
What? I mean they could write extra ones, anyone could, but The Main Official Pack Of Validation Layers™ is maintained by Khronos:
What the grandparent is saying though is "that differences between AMD and nVidia GPUs are exposed." Vulkan is so low-level that your application needs to implement workarounds for each GPU's quirks.
OpenGL was high level enough that if you didn't care too much about raw speed, the only place you got into the weeds of GPU quirks was writing your shaders. With Vulkan, the weeds of GPU quirks pop up everywhere.
Recently though, I’ve created a native application with wgpu and Rust, that I can run on my MacBook Pro M1 where it uses Metal, and on my Linux desktop where it uses Vulkan.
wgpu translates into Vulkan, Metal, Direct3D 12, Direct3D 11 or OpenGL ES depending your platform. I like it so far.
I used the guide at https://sotrh.github.io/learn-wgpu/ as a starting point and built the thing I wanted to build.
My application is a LED simulator that makes use of wgpu and Rust to visualize LED strips, and uses FFI to call functions that I’ve written for Arduino in C++. With a thin layer of wrapping that I also wrote in C++, I have made it so that the same code that runs on physical Teensy 3.2 and is controlling physical LED strips, can also be compiled and run and visualized with my LED visualizer application on my desktop or laptop computer.
This allows me to iterate more quickly as well as to better be able to debug my code, because I can do all of the development without involving the steps of flashing the firmware to a physical microcontroller and without communicating with a physical microcontroller and LED strips.
When I have done a bit of work in my simulator I then flash it to the microcontroller where the physical LED strips are controlled to see it in the real world. But being able to work in this LED visualization simulator of mine is a great boon for the development process IMO.
https://github.com/rust-windowing/winit
One can use wgpu with winit (which is more common) or, if they prefer, wgpu with sdl2. Here is an example:
https://github.com/Rust-SDL2/rust-sdl2/tree/master/examples/...
edit: but, the "next-gen Vulkan API" the article refers to, that SDL will be developing, it would be a competitor to wgpu.
Right, sorry, I should've specified that I am using winit and wgpu together, and that this is in comparison to my previous experience which includes using SDL2 alone (software rendering using SDL_Surface struct and the SDL_BlitSurface function) on one occasion during a game jam, and another time using SDL2 with Glad (OpenGL loading library) for an isometric terrain editor application that I tried to make. I think I also tried using SDL2 with GLEW at some point.
> edit: but, the "next-gen Vulkan API" the article refers to, that SDL will be developing, it would be a competitor to wgpu.
Yup, that's what prompted me to comment about wgpu, but I see how my comment ended up as incorrect because I didn't mention winit. Thanks for pointing it out.