clay
clay copied to clipboard
[Renderers/SDL3] Adds an example using SDL3 as a renderer
This example is rather basic but it does provide an example how one could setup a rendering loop between clay and SDL3.
Although SDL3 is in its infancy and doesn't have an official stable release the API has been locked so there shouldn't be any code adaptations required for this example if one was to update to a more recent SDL3 release in the future.
Awesome, thank you for the contribution! I will take a proper look at this over the next week or so 👍
Tested as working on macOS 15.2 -- thanks for this! I appreciate that you took the time to wrap in SDL_ttf. I also like that you used the new callbacks method for integration. I'm all-in on SDL3 so it's nice to see others adopting it for new, useful frameworks like Clay.
I left one comment on the SDL_ttf version, above. Otherwise, the demo works a treat.
My thoughts:
- Do you think it would be good to split this into a renderer that could be shared?
- Should this be using dynamic libraries by default?
I'd also love to see the demo essentially replicate the Raylib scroller, which would involve adding SDL_image to the build. (I'm one of those weirdos who thinks SDL_image and SDL_ttf should be part of the base library, though. 🤣 )
Tested as working on macOS 15.2 -- thanks for this! I appreciate that you took the time to wrap in SDL_ttf. I also like that you used the new callbacks method for integration. I'm all-in on SDL3 so it's nice to see others adopting it for new, useful frameworks like Clay.
I left one comment on the SDL_ttf version, above. Otherwise, the demo works a treat.
My thoughts:
- Do you think it would be good to split this into a renderer that could be shared?
- Should this be using dynamic libraries by default?
I'd also love to see the demo essentially replicate the Raylib scroller, which would involve adding SDL_image to the build. (I'm one of those weirdos who thinks SDL_image and SDL_ttf should be part of the base library, though. 🤣 )
Nice that it worked.
Regarding extensions. There is one caveat with the builtin renderer in SDL. There's no ability to render circles out of the box. I didn't look into the "border" rendering commands from clay. But my best guess is that there might be some issues with this and the border radius. This will require bespoke solutions per project that does chose to utilize clay.
For me that's a reason to avoid providing a default SDL renderer within clay and instead leave that to the user to solve for their particular case.
Granted I'm not the maintainer of the repo and if there's an interest in extending this renderer to a provided solution I'm open to help out.
There is one caveat with the builtin renderer in SDL. There's no ability to render circles out of the box.
Yes, it's been a weird API hole for decades. That said, you could render circles using SDL_RenderGeometry (providing "circles" in the form of triangles). I know that SDL_RenderPoint has too much overhead for a circle rasterizer, but I haven't tested SDL_RenderPoints, which allows for passing a bunch of points at once-- perhaps the latter would be the easiest path? I might run a test.
Another recommendation: I'd switch SDL3's tag to main as well. They added live window resizing to macOS but it's only within the past week. When 3.2.0 hits I could see pinning to that version.
You can also pin commit IDs when no branch or tag is available. I'd recommend doing that and adding a comment like "main as of 2025-01-10" for future reference.
For circles and rounded rectangles, it might be worth borrowing some code from SDL2_gfx: https://www.ferzkopp.net/Software/SDL2_gfx/Docs/html/_s_d_l2__gfx_primitives_8h.html
You can also pin commit IDs when no branch or tag is available. I'd recommend doing that and adding a comment like "main as of 2025-01-10" for future reference.
Normally I’d agree, but because SDL is a moving target with a lot of updates weekly at the moment I’d still recommend not specifying a tag or commit until 3.2.0 stable is released.