SDL
SDL copied to clipboard
libsdl-org
SDL3 Renderer - easy fragment shader injection
I know it has been planned to reimplement SDL_Renderer on top of new shiny gpu-api. I'm wondering if its possible/desirable to take it a step further - add convenient api for replacing/modifying SDL_Renderer's default fragment shader.
As someone who don't feel like complexity brought by "modern gpu programming", this could be sweet spot I think.
API example: int SDL_RenderSetFragmentShader(SDL_Renderer *renderer, ShaderID shader); // Use 0 to change back to default shader
Is this still planned? I'm wondering if I should wait for this feature or implement my own OpenGL renderer.
Is this still planned? I'm wondering if I should wait for this feature or implement my own OpenGL renderer.
You should definitely try SDL GPU. It's awesome! I'm on my way to replacing the Renderer API with GPU API.
Right now the best thing to do would be to use the GPU API directly, perhaps even copying the GPU-using 2D renderer backend right into your app, so you have a 2D thing built on it that you can trivially extend to allow custom shaders, etc.
At this moment, we aren't exposing these mechanisms from the 2D API, so this is the path of least resistance.
I still think it would be neat to be able to drive the GPU API mostly from that backend but be able to shove some custom shaders and command buffers into it as necessary; I think of Celeste, which is an otherwise-2D game that has a 3D object that spins around on the main menu, and probably a handful of posteffects on top of the 2D sprites.
...but if we offer that, it won't be for some time yet (and, as our GPU devs have pointed out: writing a thing to draw 2D sprites from the GPU API isn't that hard, so there may not be a lot of benefit from trying to make the existing 2D API cooperate when you can just own the whole thing right now).
Sounds good I'll try to implement my own backend using the GPU api doesn't seem too complicated. Thanks for the help
is there still a plan to do something like this?
I have built everything for my pixel art games on top of SDL2 renderer, the only thing I would like to add is some simple Shaders for day/night, etc to apply mainly fullscreen, and maybe something in the future for better lighting.
Diving into SDL GPU does not make a lot of sense for me, since the sdl2 renderer api is otherwise just fine for my needs..
is there still a plan to do something like this?
I have built everything for my pixel art games on top of SDL2 renderer, the only thing I would like to add is some simple Shaders for day/night, etc to apply mainly fullscreen, and maybe something in the future for better lighting.
Diving into SDL GPU does not make a lot of sense for me, since the sdl2 renderer api is otherwise just fine for my needs..
I feel you man. I'm in the same situation. SDL RENDER is a nice abstraction for my project, especially since geometry api was introduced. I'd rather consider GPU as special device capable of drawing triangles very fast rather than a general purpose parallel computing device perceived by most people nowadays. However, it looks like the SDL team is not motivated enough to make final decision yet. Given so many new developers are diving into modern gpu programming, odds are even dimmer IMHO.
@thatcosmonaut wrote an article about this, which tries to explain how "easy" it is to write your sprite renderer on top of the GPU api.
Links to more articles can be found on our wiki.
Understandable it's easy to create a 2D renderer using the GPU API. However the downsides of this is SDL3 dropped OpenGL & GLES for modern convenience.
This now means platforms like Web that relied on ES 2.0 have essentially been dropped when it comes to the GPU API. The WebGPU backend would be great however it's still not standard by any means. Some browsers have it enabled by default others require manual flags, mobile browsers are pretty much out of the question as hardly any support WebGPU at all regardless of flags. Even if WebGPU backend was added tomorrow it would change much for real world production applications.
I love the direction SDL is going, however the sudden change means porting existing projects to SDL3 is pretty much impossible and will stay that way for what I believe is years to come in terms of Web. I definitely think this leap to drop OpenGL was taken far too early. I've read that SDL will eventually switch the Renderer API to use the GPU API which seems even more problematic for the Web platform?
A SDL_Renderer based Shader API is definitely worth looking in at from my perspective.
SDL3 did not drop OpenGL and GLES. They are still available and the SDL opengl and opengles2 renderers will remain indefinitely. All of the existing tricks to use GL shaders with those renderers should still work.
The addition of the GPU API is an optional extension for people who want to use it. There's no reason you can't migrate an OpenGL SDL2 application to an OpenGL SDL3 application, and many people have done this.
I'm directly talking about the GPU API not having OpenGL or GLES support. Therefore how are we supposed to upgrade our old or even new projects using Web (Emscripten) to this new GPU API if you no longer support the backend?
Even if WebGPU was implemented it isn't widely available on all the browsers and WebGPU has been out for a few years now, definitely don't see it being available on all browsers especially mobile variants anytime soon.
I understand the SDL Renderer API itself still has OpenGL & GLES compatibility that's not the issue.
The issue is how are we supposed to use shaders by switching to the GPU API if the backend is not supported anymore? Writing a 2D renderer on top of the GPU API isn't an option for some cases.
The GPU API never supported OpenGL or GLES. If you're using that and need that, then you shouldn't use the GPU API. Using the GPU is not any kind of requirement.
But aren't we talking about a Shader API for the SDL_Renderer? Im giving a valid reason to potentially look in to it because not everyone can use the GPU API because of what I previously mentioned. 😄
I understand it's optional however I would love to be using it. Meaning what Icculus said "Right now the best thing to do would be to use the GPU API directly, perhaps even copying the GPU-using 2D renderer backend right into your app, so you have a 2D thing built on it that you can trivially extend to allow custom shaders, etc." Is not a valid route I can take.
It's fair enough if you don't see reason to implement it or it doesn't align with your goals. I'm just mentioning why its valid,
Thanks!