Last night I tried for maybe about 6 hours so many combinations of efforts to compile a C++, SDL3 and Lua program on Windows, with different IDEs, build systems, compilers, package managers etc. Finally I'm just giving up and using VS with CMake and vcpkg. The main problem is that there's way too many words on all those documentation pages. It would have taken 3 or 4 days to read them all, and maybe only 2 hours worth of it would have been helpful or relevant at all.
I agree. I used chatgpt to write a makefile to compile sokol+Tracy. It's a pretty solid, generic makefile. But "build system complexity" pushed me away from sdl, magnum graphics and bgfx into the arms of sokol.
And I'm a 10+ year gamedev.
Out of all of c++'s sins, the lack of a solid integrated build system is the one that bites me the most.
My theory is that good C++ devs haven't yet made a simple yet powerful build system because they're too busy making lots and lots of money writing enterprise C++.
Something about me has always wanted to learn and master C++. I've read through Stroustrup's book almost entirely, and still never written a single line of C++. I don't know why I have this goal in life, but I do. This project still doesn't do that, since I'm just wrapping SDL3 with QuickJS and will probably almost entirely just write C functions to do it with. But a man can dream.
I wonder if there is a SDL3 wrapper that comes with a scripting language[0], hot reload and build scripts for every major platform.
Love2D seems close to that, but afaik it doesn't support SDL3 features like the new GPU API.
[0]: It's not like I'm allergic to C++, but I firmly believe when developing something that is mostly interactive, such as complex GUI or games, a language that is garbage collected and can be hot reloaded would be much more apt.
You can build a project linking SDL3 with Lua and have access to all of the features of SDL3, with the obvious caveat that you'll have to code the rest of the owl yourself, but it isn't difficult. I have a basic CMake script that I use for projects and it works fine. (also, obviously you can just run the Lua code locally and skip the build process altogether when developing.) I use LuaJIT though, and the FFI generator here[0].
Mainly it just reminded me of what happened last night and seemed like good timing because of the similarity, but also I appreciate blog posts that are short and get right to the point of how to do something.
Half of the problems I got past were thanks to odd blog posts like this with code snippets that I found on google and got me unstuck immediately.
Thanks for sharing a simple setup that avoids SwiftPM. It is nice to have more options.
Swift has to shed the perception that it only works on apple platforms. I've found the the C++ interop to be pretty good for my computer vision use cases.
The build process requires you to have a C library built with its own dependencies. I don’t think it’s very common to do that with SwiftPM, hence it would require extra work for it to happen.
CMake support started as a community project but was adopted officially by Apple after they started adopting some Swift in the compiler codebase – an extremely large and complex CMake project – so the support is extremely robust now.
Snap, I did something similar a few weeks ago (without the cool PoC) - github.com/davidrpiper/SwiftCmakeModulemapMVP
Now that Swift + SourceKit LSP + VS Code is a viable environment, and CMake supports C/C++ and Swift interop out-of-the-box, I'm keen to start using Swift for more cross-platform things.
Hah I just recently was doing some soul searching for a game dev environment to get started with. I did a wee bit of 2D game dev in college 15 years ago, and wanted to scratch the same itch.
At this point, I demand a good IDE experience: as much intellisense as possible, great debugger, hot reloading.
Anyway, C# and MonoGame was what won at the end of the day, at least to just get the ball rolling. Rider is a great IDE, and MonoGame… at least has great getting started documentation to get me going again. Once I knock out a few cutesy games I’ll probably go build my own thing on top of SDL3, so that I’m not held back by MonoGame. Also the MonoGame content builder is just completely broken on Mac, so on the side I am building my own Rider plugin to bring actually good intellisense to the mgcb file, so that I don’t need the broken editor gui (all it does is manage the mgcb file anyway, arguably should have just been an IDE plugin the whole time)
I tried Dragonruby, really wanted to like it, but the development experience is just… not there. It live reloads, but seems to offer no IDE tooling whatsoever. They talk a lot about emacs, maybe you’re supposed to use it with emacs, which I just have zero interest in doing. You’re also not using MRI, or the full Ruby language, so a lot of tooling for “normal Ruby” may not work. C# is just C# with MonoGame, I can use all the tools, import all the nuget packages (if you really want to), etc.
I felt like going with a C based project would lock me out of having hot reloading, but that might not be true, please let me know if I am wrong!. I know of a C++ hot reloading thing specifically made for game dev, it’s in my notes somewhere, just not sure if it’s suitable for use (you sure do have to sift through lots of abandoned experimental stuff in this world)
Ah yeah Í keep seeing it come up, I will take a look! This weekend was gonna toy with C++ to rebuild what I got done with MonoGame, but a next mini experiment can perhaps be Odin!
Since it uses SDL3, it should be able to do more than 2D, right? Last time I checked SDL3 wraps around a lot of GPU API that you can pretty much do whatever you can do with WebGPU.
Yep, I've been meaning to get a Swift + SDL project working.
The language itself is not limited to Apple platforms, and there are compilers for many others, but until now all the surrounding tooling (IDEs, Swift Package Manager, build toolchain(s), C/C++ interop) has been less than ideal for all non-Apple platforms. Arguably less than ideal on Apple platforms too in some cases ;)
There is still a big difference between "I have Xcode" and "I have VSCode + a large manual toolchain", but the gap is closing. CMake can also generate Xcode projects which is a nice touch when bringing cross-platform code back to Apple platforms.
Readit News
And I'm a 10+ year gamedev.
Out of all of c++'s sins, the lack of a solid integrated build system is the one that bites me the most.
Try the breakout example, I play around with it a lot. You’ll just need the Zig 0.14 compiler and it should be painless.
Love2D seems close to that, but afaik it doesn't support SDL3 features like the new GPU API.
[0]: It's not like I'm allergic to C++, but I firmly believe when developing something that is mostly interactive, such as complex GUI or games, a language that is garbage collected and can be hot reloaded would be much more apt.
Code reload (because it uses MRuby) is just :chef-kiss:
[0]https://github.com/sonoro1234/LuaJIT-SDL3
- vcpgkg manifest file
- done
The problem is people pretending Windows is UNIX.
And UNIX community got lucky Apple decided to go with NeXTSTEP and not BeOS, otherwise those shiny fruit laptops would also be their own thing.
I do gamedev on Linux for this reason. With Nix it isn't even that bad to cross-compile.
Half of the problems I got past were thanks to odd blog posts like this with code snippets that I found on google and got me unstuck immediately.
Swift has to shed the perception that it only works on apple platforms. I've found the the C++ interop to be pretty good for my computer vision use cases.
Now that Swift + SourceKit LSP + VS Code is a viable environment, and CMake supports C/C++ and Swift interop out-of-the-box, I'm keen to start using Swift for more cross-platform things.
At this point, I demand a good IDE experience: as much intellisense as possible, great debugger, hot reloading.
Anyway, C# and MonoGame was what won at the end of the day, at least to just get the ball rolling. Rider is a great IDE, and MonoGame… at least has great getting started documentation to get me going again. Once I knock out a few cutesy games I’ll probably go build my own thing on top of SDL3, so that I’m not held back by MonoGame. Also the MonoGame content builder is just completely broken on Mac, so on the side I am building my own Rider plugin to bring actually good intellisense to the mgcb file, so that I don’t need the broken editor gui (all it does is manage the mgcb file anyway, arguably should have just been an IDE plugin the whole time)
I tried Dragonruby, really wanted to like it, but the development experience is just… not there. It live reloads, but seems to offer no IDE tooling whatsoever. They talk a lot about emacs, maybe you’re supposed to use it with emacs, which I just have zero interest in doing. You’re also not using MRI, or the full Ruby language, so a lot of tooling for “normal Ruby” may not work. C# is just C# with MonoGame, I can use all the tools, import all the nuget packages (if you really want to), etc.
I felt like going with a C based project would lock me out of having hot reloading, but that might not be true, please let me know if I am wrong!. I know of a C++ hot reloading thing specifically made for game dev, it’s in my notes somewhere, just not sure if it’s suitable for use (you sure do have to sift through lots of abandoned experimental stuff in this world)
[1] https://news.ycombinator.com/item?id=19677201
It loads Aseprite files automatically, manages animations, collisions, networking, what have you.
My (limited) understanding is that Swift is mostly used to make iOS apps.
The language itself is not limited to Apple platforms, and there are compilers for many others, but until now all the surrounding tooling (IDEs, Swift Package Manager, build toolchain(s), C/C++ interop) has been less than ideal for all non-Apple platforms. Arguably less than ideal on Apple platforms too in some cases ;)
There is still a big difference between "I have Xcode" and "I have VSCode + a large manual toolchain", but the gap is closing. CMake can also generate Xcode projects which is a nice touch when bringing cross-platform code back to Apple platforms.
macOS, Linux, Windoze