Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Would you be open to an experiment with SDL3 (and the gpu api)? #40

Open
photex opened this issue Aug 31, 2024 · 4 comments
Open

Would you be open to an experiment with SDL3 (and the gpu api)? #40

photex opened this issue Aug 31, 2024 · 4 comments

Comments

@photex
Copy link
Contributor

photex commented Aug 31, 2024

Heyo!

Before I noodle a bit, then present my findings I wanted to get a vibe check.

With the recently merged GPU API there is now a very nice way to use the modern platform graphics APIs. No more OpenGL! :D Compute shaders ahoy! :D And because it's SDL we'd have gamepads! And SDL is honestly amazingly small and fast given the wide platform support that is intensively tested.

In regards to the GPU api, the shader compilation likely presents the biggest question for Apple/metal targets. sokol_shaderc could still work I believe. The machengine dxc would not work as I understand it. glslc could possibly work, but that would mean Apple developers would have to use moltenvk.

If it's way off the mark for your concept of delve-framework then all good, I'll leave it at that. If there is some interest then I'd like to explore SDL with delve and share anything I arrive at.

@Interrupt
Copy link
Owner

This would be awesome, I've been trying to architect the platform API where the actual implementations could be switched out to handle just this kind of thing. I'd rather not get stuck to one API for anything if possible.

@photex
Copy link
Contributor Author

photex commented Sep 16, 2024

I did take notice of that so it would remain my goal to keep things switchable. Once I get this scaffolded I'll open a draft PR to keep it out in the open for any feedback.

@Interrupt
Copy link
Owner

Interrupt commented Sep 23, 2024

After doing a bit of an audit in the platform/graphics.zig area of the code, it looks like there are a few places where Sokol types are used directly that will need to be abstracted out into the implementation layer, mainly in Texture and RenderPass - both of these probably need to do what Shaders do, where they have an implementation that can be easily switched out at some point during app setup.

Also I've been musing a bit on how to switch out the implementations at compile time. Right now the shader implementation setup right now just looks like:

pub const ShaderImpl = sokol_gfx_backend.ShaderImpl;

Maybe there is some way to set these up somewhat dynamically at compile time based on some new Graphics Backend type that we set in the App setup. Would love to hear some proposals on how best to do that.

@photex
Copy link
Contributor Author

photex commented Sep 24, 2024

So my first step was getting SDL integrated into the build, based on what's been done for SDL2, but I instead chose to keep the zig build setup and the SDL sources separated (akin to ziglua).
For the moment these are living in my fork under 3rdparty, but possibly it's more desirable to live in it's own repo. (I figure that's easier to decide later)
I also noticed that the graphics work will be a bit more involved than the window and events, so my plan was to start by having SDL be used first for window, context, and input and keep sokol for graphics.
For sokol/app.zig I did need to move some static functions into the associated App struct.

I'll open that draft PR in a moment once I rebase this stuff on to your recent stuff on main. :D

@photex photex mentioned this issue Sep 24, 2024
23 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@Interrupt @photex and others