SDL3 Platform Support

[photex]

As discussed in #40, this PR is the WIP for having SDL3 support.

My expectation is that this will get a bit messy, but ultimately a squash before merging will trim any of the missteps and so on.

Current Goals:

• Build SDL3
  • Windows
  • Linux
  • MacOS
  • Emscripten
• Implement the App backend
  • Windows
  • Input
    • Gamepads
  • Graphics context creation
  • ImGUI
  • Display scale query
  • Correctly initialize sokol_gfx
    • Windows
    • MacOS
    • Linux
    • Emscripten
  • Emscripten main loop
• Sokol App backend behavior preserved
• CI for each platform to ensure everything builds
• Allow applications to select a backend at build time
  • Sources only fetched when SDL platform selected
  • SDL only built when that platform is selected

[photex]

SDL Window ahoy... It's looking kinda messy behind the scenes, but it was just to get to this point. Now I can walk some stuff back or clean some things up.

Screencast_20240930_155527.mp4

[Interrupt]

Whoah, that is great progress!

[photex]

Ok, so now you can freely use either backend:

zig build -Dplatform_backend=sokol (which is also just the default) or zig build -Dplatform_backend=sdl

Please excuse the wide overreach in the current diff. I tried something, and didn't want to push something that didn't build. I'll reverse a lot of the platform module restructure.

I found the platform/app.zig situation to be pretty confusing. I thought that the platform module itself already provided the public api so there was no need for delve.platform.app.

It also made things a bit easier to reckon with in terms of the build time selection of the backend and simplified some of the imports else where in the platform files.

I still think that there can be a better name for platform/app.zig, but I think perhaps the build time selected backend could become the platform.app instead. That would mean that perhaps the platform apis that work as a facade aren't needed?

I'll noodle a bit and start reverting the changes to the examples. :D

[Interrupt]

Yeah, is a bit confusing right now. The top level framework/app.zig is really the client application config setup, which maybe could be renamed to delve_framework_app or something, and the thinking was the common backend logic for windowing and rendering would live in the framework/platform layer, hence the app there.

I like the idea of the platform layer holding the common code, and then the actual backends just needing to implement a small set of functions instead of there being a bunch of copy+paste between backends, but this is the first time this has been tried so I'm sure some changes will shake out of it.

[photex]

Yep, that's the right way to go. I've reverted things so the diff is readable again.
Next I need to get the ImGUI events hooked up, and I can figure out builds for other platforms.

[photex]

I added github actions that build things with both backends. Windows and Linux are working (I haven't tested windows binaries yet... need to find a machine to set windows up on) and I've fixed the build so that SDL is only actually built when you select that backend.

I'm going to base the imgui event handling on what I see with sokol app, I believe another keyboard map will be needed, but I think otherwise it's fairly simple.

That will mean there needs to be more considerations for swapping out the RHI (if this is the right way to think of sokol vs SDL_gpu vs ). But this definitely makes it clear that working on the platform stuff first while maintaining sokol was the right idea. :D

I believe emscripten could be supported with SDL3. Unfortunately it's not part of the emsdk yet so I'll try to build it. It would be sweet to have gamepads for that target.

Also, I plan to rebase and squash all my garbage commits soon.

[photex]

Ok, ImGUI hooked back up. Need to try and seal the deal on building for each platform now. trying to line up some way to actually test them

[Interrupt]

This is some serious progress! Making the builds only include SDL3 when needed is huge, that's exactly the kind of thing I've been thinking about as it makes cross platform builds way easier when the dependency list is smaller. This seems really close to having a new app layer backend.

[photex]

😮‍💨 realized I was running sokol_app unintentionally lol

[photex]

Ok, build of SDL for emscripten is working. The mainloop is still not set up correctly though. This is more what I expected originally.

I also just realized that even for the sokol backend, the windows builds aren't initializing sokol_gfx correctly. So I'll figure out what I broke. :D Obviously there shouldn't be any change in behavior or results for that backend!

[photex]

Alright, so SDL builds and runs under emscripten, but I'm learning that sokol_app definitely handles a lot of details regarding the viewport and surface under emscripten.

[Interrupt]

I'd believe that, looking through the Sokol source they seem to have a lot of checks for the web build case.

[photex]

In this case the window resizes but not the viewport being rendered into. It maintains the initially requested dimensions.
flooh explained some things to me and pointed at examples of what sokol_app does in these cases.

If I make the window resizeable for a desktop build everything is working as expected. But for the web you end up needing to manage some things for the webgl surface to stay in sync with the canvas.

On the desktop front, for windows, the combination of sokol_gfx and SDL isn’t quite done because at the beginning of the frame we need to provide a pointer to a directx device which the glue lib uses sokol_app to do.

Either way, slowly getting there. :)

[Interrupt]

Resizing isn't handled yet by the Delve Framework, so that behavior at least matches the current Sokol implementation. This is on my radar to flesh out though