Open photex opened 2 months ago
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.
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.
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.
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
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.