Windows Support
Hi, this is great work! I have been separately working on a similar projects, though yours is far ahead at this point.
I'd love to use yours instead, your final API is very similar to mine, the only real difference I included a SwiftUI-like API for defining a Game.
But I need Windows support, what exactly is blocking this from being implemented atm? If you have a general direction or starting point I might be interested in contributing to your project rather than continuing with my own.
Again, really great to see someone else working on this!
@shaps80 Thanks for the generous words. Contributions are certainly welcomed.
Windows support, or lack thereof, is blocked by constraints on my time and resources; I've yet to set up a VM install, and configure a SwiftSDL dev environment on Windows. Unfortunately, I don't have an immediate timeframe for when I can come back and work on this.
Are you interested in adding it and submitting a pull-request?
Hey @KevinVitale sorry for taking so long to get back to you. I can't promise anything atm, but I am occasionally revisiting my project and I do in fact have Swift dev setup on a Windows Surface already as I've been developing my own project there in VSCode when testing windows.
Next time I revisit the project (might be next week as I'm on holiday and will have some free time), I'll see if I can clone this on the Surface and see what works or doesn't work.
Will keep you updated, thanks!
I invested some time in this today; however, my Windows ARM VM (via Parallels) isn't compiling the SDL3 source properly (build scripts are for x86-64 only).
Any progress on your end?
@KevinVitale unfortunately no such luck. I did take a brief look after our last messages above, but there were many compile errors and from memory it was unclear to me how to resolve. As you mentioned build scripts etc wouldn't work since I have the latest Surface with is ARM based. I'm super interested in this, but atm I can't invest any time working on the this specifically. I really wish I could.
Hi guys, if it’s helpful, there are pre-built Windows binaries here: https://github.com/mmozeiko/build-sdl3
I likewise keep trying to find time to get this working and have this link set aside for that rainy day.
Hi, has there been any progress on this? As far as I can see, you're the only one that has an active project for binding SDL3 in Swift but as a Windows user I can't use it
@LouChiSoft I occasionally look into this; however, I'm no Windows dev expert. The biggest challenges are configuring the Package file with the proper flags/paths, and also be certain that it runs on x86_64 and arm64.
As always, contributions are certainly welcomed.
I'll continue to poke at this task, perhaps with some help from AI, when I'm able to.
I'm a complete noob when it comes to Swift, so I wouldn't know how to contribute a new platform. But in terms of building on SDL3 on Windows from the root of the SDL repo I can just do:
cmake -B ./build
cmake --build ./build --config=release
Assuming you are using a multi-config generator like the default VS one for Windows. Is there any specific flags you need?
Edit: on an x86 machine
@LouChiSoft Yes, I've built SDL using CMake many times on macOS and Linux.
For Apple platforms, I've provided an xcframework bundle that automatically gets links when pulling in the package.
For Linux users, package managers (apt, etc.) can be used to install SDL3, and is linked at runtime.
Swift-specific instructions for Windows which leverages the Swift Package Manager(SPM) is what's needed. If you can provide that in a way that can be tested reliably, that would be helpful.
Okay, so I have been trying to get artifact bundles working since it seems like it would be the most user convenient solution (the SDL binary can be stored on GitHub or somewhere and then pulled as part of the package). And I can get SwiftPM to recognise that there is an artifact binary, but no matter what I try it always ends up returning a "artifact bundle does not contain a binary" error
Good news, I got the artifact bundle working (turns out it had nothing to do with the binary). I am doing some more changes locally like seeing if I can get the DLL to auto-copy to the build directory on Windows since it only copies the .lib at the moment.
If it works I can fork the repo and make a PR