4 ms·

If you only want to support Windows/Linux/Android, then sure, you can definitely argue that the SDL GPU API is bloat. But if you want to support Apple's operat

by caspar 2y ago

If you only want to support Windows/Linux/Android, then sure, you can definitely argue that the SDL GPU API is bloat. But if you want to support Apple's operating systems then you're stuck with OpenGL 4.1 (officially deprecated by Apple 5 years ago) - so no modern GPU features like compute shaders. You can go the Vulkan route and use MoltenVK for Apple systems, but Vulkan is quite a step up in complexity from OpenGL ("1000 lines of code for a triangle" as people like to say). The goal for SDL3's GPU API is to give you a more approachable (but still plenty flexible) alternative to that. And similar story for consoles, presumably. Apparently lots of people asked for "SDL_render but can you add shader support that works for all platforms", so that's the origin story. SDL3 does also add a higher level audio API - I don't know much about its merits.

caspar 2y ago
Ah, I managed to dig up the original announcement post[0]; relevant snippet: > But this is terrible advice in 2021, because OpenGL, for all intents and purposes, is a deprecated API. It still works, it's still got some reasonably modern features, but even if you add up the 22 years Microsoft spent trying to kill it with Apple's seven-or-maybe-twenty, it doesn't change the fact that the brains behind OpenGL would rather you migrate to Vulkan, which is also terrible advice. > It seems bonkers to tell people "write these three lines of code to make a window, and then 2000 more to clear it," but that's the migration funnel--and meat grinder--that SDL users are eventually going to get shoved into, and that's unacceptable to me. [0]: https://www.patreon.com/posts/new-project-top-58563886 https://www.patreon.com/posts/new-project-top-58563886
hgs3 2y ago
But why does the GPU API need to be in mainline SDL? Couldn't it be a separate project like SDL_net, SDL_mixer, SDL_image, and SDL_ttf? I would think that as a separate project "SDL_gpu" could be versioned independently, evolve independently, and not be obligated to support every platform SDL itself supports. In fact if "SDL_gpu" only required a windowing context, then it could presumably integrate with SDL2 and non-SDL applications!
- gary_0 2y ago
  See dottrap's comment: https://news.ycombinator.com/item?id=41397198 https://news.ycombinator.com/item?id=41397198 SDL needs to be able to render graphics efficiently, but the SDL2 way is no longer sufficient. Since SDL3 is a major version change, it makes sense to overhaul it while a variety of other API-breaking improvements are being made.
- caspar 2y ago
  AFAICT, if you don't want to use it then you don't have to - just like you didn't have to use SDL_render in SDL2. That is what was pitched by maintainer Ryan Gordon[0][1] at least. [0]: https://github.com/libsdl-org/SDL_shader_tools/blob/main/docs/README-SDL_gpu.md https://github.com/libsdl-org/SDL_shader_tools/blob/main/doc... , though the approach that ended up getting merged was an initially-competing approach implemented by FNA folks instead and they seem to have made some different decisions than what was outlined in that markdown doc.
  - gary_0 2y ago
    While using SDL for drawing is optional (and seldom done if you're doing 3D) I would like to add that its drawing API is useful to have out-of-the-box so that new/basic users can get stuff on screen right away without having to write their own high-level graphics engine first.
creata 2y ago
Slightly off-topic, but where's the complexity of Vulkan (the 1000 lines) coming from? My memory tells me that most of the misery is from the window system integration, and that the rest is pretty pleasant.
- davemp 2y ago
  You have to wrangle a bunch of complex structs into rendering pipelines before you can really do anything at all: https://vkguide.dev/docs/new_chapter_3/building_pipeline/ https://vkguide.dev/docs/new_chapter_3/building_pipeline/
- cyber_kinetist 2y ago
  Counter-intuitively, when you actually start caring about performance (easy to write "working" Vulkan code, hard to write efficient Vulkan code that competes with DX11 driver magic)

by caspar 2y ago

caspar 2y ago

Ah, I managed to dig up the original announcement post[0]; relevant snippet: > But this is terrible advice in 2021, because OpenGL, for all intents and purposes, is a deprecated API. It still works, it's still got some reasonably modern features, but even if you add up the 22 years Microsoft spent trying to kill it with Apple's seven-or-maybe-twenty, it doesn't change the fact that the brains behind OpenGL would rather you migrate to Vulkan, which is also terrible advice. > It seems bonkers to tell people "write these three lines of code to make a window, and then 2000 more to clear it," but that's the migration funnel--and meat grinder--that SDL users are eventually going to get shoved into, and that's unacceptable to me. [0]: https://www.patreon.com/posts/new-project-top-58563886 https://www.patreon.com/posts/new-project-top-58563886

hgs3 2y ago

But why does the GPU API need to be in mainline SDL? Couldn't it be a separate project like SDL_net, SDL_mixer, SDL_image, and SDL_ttf? I would think that as a separate project "SDL_gpu" could be versioned independently, evolve independently, and not be obligated to support every platform SDL itself supports. In fact if "SDL_gpu" only required a windowing context, then it could presumably integrate with SDL2 and non-SDL applications!

gary_0 2y ago
See dottrap's comment: https://news.ycombinator.com/item?id=41397198 https://news.ycombinator.com/item?id=41397198 SDL needs to be able to render graphics efficiently, but the SDL2 way is no longer sufficient. Since SDL3 is a major version change, it makes sense to overhaul it while a variety of other API-breaking improvements are being made.
caspar 2y ago
AFAICT, if you don't want to use it then you don't have to - just like you didn't have to use SDL_render in SDL2. That is what was pitched by maintainer Ryan Gordon[0][1] at least. [0]: https://github.com/libsdl-org/SDL_shader_tools/blob/main/docs/README-SDL_gpu.md https://github.com/libsdl-org/SDL_shader_tools/blob/main/doc... , though the approach that ended up getting merged was an initially-competing approach implemented by FNA folks instead and they seem to have made some different decisions than what was outlined in that markdown doc.
- gary_0 2y ago
  While using SDL for drawing is optional (and seldom done if you're doing 3D) I would like to add that its drawing API is useful to have out-of-the-box so that new/basic users can get stuff on screen right away without having to write their own high-level graphics engine first.

creata 2y ago

Slightly off-topic, but where's the complexity of Vulkan (the 1000 lines) coming from? My memory tells me that most of the misery is from the window system integration, and that the rest is pretty pleasant.

davemp 2y ago
You have to wrangle a bunch of complex structs into rendering pipelines before you can really do anything at all: https://vkguide.dev/docs/new_chapter_3/building_pipeline/ https://vkguide.dev/docs/new_chapter_3/building_pipeline/
cyber_kinetist 2y ago
Counter-intuitively, when you actually start caring about performance (easy to write "working" Vulkan code, hard to write efficient Vulkan code that competes with DX11 driver magic)