-
The current SDL GPU API does not intend to use this shader language. Instead, users are expected to provide shaders in the relevant format for each underlying graphics API [1], using whatever custom pipeline they desire.
One of the developers made an interesting blog post motivating this decision [2] (although some of the finer details have changed since that was written).
There is also a "third party" solution [3] by another one of the developers that enables the use of SPIR-V or HLSL shaders using SPIRV-Cross and FXC/DXC, respectively (NB: It seems this currently wouldn't compile against SDL3 master).
[1] https://github.com/libsdl-org/SDL/blob/d1a2c57fb99f29c38f509...
[2] https://moonside.games/posts/layers-all-the-way-down
[3] https://github.com/flibitijibibo/SDL_gpu_shadercross
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
It exists, but IMO it's not a good choice.
First of all, it doesn't support RenderGeometry or RenderGeometryRaw, which are necessary for high-performance 2D rendering. I doubt it will support any of the GPU stuff at this rate, as the geometry rendering is pretty much a prerequisite. Maybe both will land all at once, though. To wit, the relevant issue hasn't seen much activity: https://github.com/Rust-SDL2/rust-sdl2/issues/1180
Secondly, the abstractions chosen by rust-sdl2 are quite different from those of SDL2 itself. There seems to have been an aggressive attempt by the Rust library authors to make something more Rust-friendly, which maybe has made it more approachable for people who don't know SDL2, but it has IMO made it less approachable for people who do know SDL2. The crate gets plenty of downloads, so maybe it's just me.
-
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/doc...
[1]: NB: the approach that ended up getting merged was an initially-competing approach implemented done by FNA folks instead and they seem to have made some different decisions than what was outlined in that markdown doc.
-
bgfx
Cross-platform, graphics API agnostic, "Bring Your Own Engine/Framework" style rendering library.
I previously integrated bgfx [1], which allows you to write graphics code and shaders once and supports consoles, with SDL2 stack and Swift [2]. It was quite a nice experience, especially for someone who had never worked with any of these tools before. I'm excited for SDL3 as it introduces console abstractions, eliminating the need for additional dependencies for the GPU API, especially for someone who casually experiments with graphics. Moreover, Godot officially supports the Steam Deck, and hopefully, more consoles will be supported in the future. On a related note, Miguel de Icaza is advocating for Swift adoption in Godot, and he is working on porting the editor to SwiftUI on iPad, which is quite interesting to see the progress [3].
[1] https://bkaradzic.github.io/bgfx/overview.html
[2] https://github.com/bgbernovici/myndsmith
[3] https://blog.la-terminal.net/xogot-code-editing/
-
WebGPU has a (mostly) standardized C API: https://github.com/webgpu-native/webgpu-headers
-
This article from the main author of the API describes how the buffer cycling works: https://moonside.games/posts/sdl-gpu-concepts-cycling/
Examples will be based on this repo, I believe: https://github.com/TheSpydog/SDL_gpu_examples
-
wgpu supports WebGPU: https://github.com/gfx-rs/wgpu :
> While WebGPU does not support any shading language other than WGSL, we will automatically convert your non-WGSL shaders if you're running on WebGPU.
-
Unreal/Unity are not the only solutions. There is also bgfx (https://github.com/bkaradzic/bgfx), which is quite popular and sokol gfx (https://github.com/floooh/sokol) which I know of. Of course there are many more lesser known ones.
-
Is this related to https://github.com/grimfang4/sdl-gpu ? Or is it a completely separate thing with the same name?
-
-
The Rust wgpu project has an alternative C API which is identical or at least closely matched (not sure which) the official webgpu.h header. For instance all examples in here are written in C:
https://github.com/gfx-rs/wgpu-native/tree/trunk/examples
-
myndsmith
Experimental Swift wrapper around the SDL2 ecosystem (SDL2, SDL2_TTF, SDL2_Mixer, SDL2_Image) and BGFX.
I previously integrated bgfx [1], which allows you to write graphics code and shaders once and supports consoles, with SDL2 stack and Swift [2]. It was quite a nice experience, especially for someone who had never worked with any of these tools before. I'm excited for SDL3 as it introduces console abstractions, eliminating the need for additional dependencies for the GPU API, especially for someone who casually experiments with graphics. Moreover, Godot officially supports the Steam Deck, and hopefully, more consoles will be supported in the future. On a related note, Miguel de Icaza is advocating for Swift adoption in Godot, and he is working on porting the editor to SwiftUI on iPad, which is quite interesting to see the progress [3].
[1] https://bkaradzic.github.io/bgfx/overview.html
[2] https://github.com/bgbernovici/myndsmith
[3] https://blog.la-terminal.net/xogot-code-editing/
-
The current SDL GPU API does not intend to use this shader language. Instead, users are expected to provide shaders in the relevant format for each underlying graphics API [1], using whatever custom pipeline they desire.
One of the developers made an interesting blog post motivating this decision [2] (although some of the finer details have changed since that was written).
There is also a "third party" solution [3] by another one of the developers that enables the use of SPIR-V or HLSL shaders using SPIRV-Cross and FXC/DXC, respectively (NB: It seems this currently wouldn't compile against SDL3 master).
[1] https://github.com/libsdl-org/SDL/blob/d1a2c57fb99f29c38f509...
[2] https://moonside.games/posts/layers-all-the-way-down
[3] https://github.com/flibitijibibo/SDL_gpu_shadercross
-
https://github.com/shlomnissan/sdl-wasm :
> A simple example of compiling C/SDL to WebAssembly and binding it to an HTML5 canvas.
erik-larsen/emscripten-sdl2-ogles2:
-
https://github.com/erik-larsen/emscripten-sdl2-ogles2 :
> C++/SDL2/OpenGLES2 samples running in the browser via Emscripten
IDK how much work there is to migrate these to SDL3?
Are there WASM compilation advantages to SDL3 vs SDL2?
-
-
I'm not related to hnlmorg, but I'm assuming the project they refer to is mxtty [1], so check for yourself.
[1]: https://github.com/lmorg/mxtty
-
Check the donut examples: https://github.com/NVIDIAGameWorks/donut_examples
A bit dense, but I find it easier to understand and maintain than bgfx. Not as easy as sokol or magnum.
Related posts
-
installing SDL2 bindings fails on __stack_chk_fail and __stack_chk_guard when building, any ideas?
-
"Unknown GLUT entry glutInit" -- Failing to get Gloss working on Windows
-
Want to a 3D game without a game engine but not having to deal with opengl stuff ?
-
Looking for a 2D/3D rendering layer for C++
-
Sharing my biggest project