> So, if you want to build games using raylib, why not learn learning or use Swift for that?
Never ever worked for me. Imagine, you actually learned basic Swift and Raylib, now you want "advanced" features in your game like navigation/pathfinding, model loading, ImGui, skeletal animation (those are actually vital for gamedev).
You realize that
- Navigation is only ReCast which is pure C++ library,
- ImGui has C++ API as first-class citizen,
- Decent animation with compression is only open-sourced by OzzAnimation which is pure C++ project.
For gamedev interfacing with C is never enough, half of ecosystem is built heavily on C++. Even C++ interop is not enough (see Dlang). Without all those libraries you are bound to make boring 2d platformers.
Dear ImGui via the C bindings is actually quite nice and not much less convenient than the C++ API (the only notable difference is that the C API has no overloads and default params).
E.g. here's a control panel UI (from the below ozz-animation sample) with the 'Dear Bindings' approach (using a custom 'ig' prefix)):
TL;DR: quite a few C++ libraries out of the game-dev world are actually quite easy to access from C or languages that can talk to C APIs, mainly because the game-dev world typically uses a very 'orthodox' subset of C++ (no or very restricted C++ stdlib usage, no rtti, no exceptions, ideally no smart pointers in the public API).
Raylib has a C API though, and this is 'easy-mode' in any language (even without integrated bindings generation like Swift or Zig have - e.g. it's fairly trivial to write a bindings generator that uses Clang's ast-dump json file format as input and translates the API declarations into another language.
A more interesting question would be how well the C++ interoperability works that was added in Swift 5.9, does it work with all C++ headers, even headers that make extensive use of template code. Also how does Swift extract information needed for lifetime tracking, e.g. C++ APIs that return smart pointers and object lifetime ends on the caller's side. Does this only work for C++ stdlib smart pointer types, or are custom types also supported.
> A more interesting question would be how well the C++ interoperability works
They’re using it in their work on FoundationDB. Looks good, but has limitations. Swift can call C++ and vice versa, Swift classes can inherit from C++ and vice versa, but not for all code, and may need work adding annotations on the C++ side. See https://github.com/apple/foundationdb/blob/main/SWIFT_GUIDE.....
Out of curiosity, how does the size and performance of the generated WASM compare to just compiling the same Raylib example from the equivalent C code via Emscripten? In other words, how much overhead does the choice to use Swift add here or in general?
I might be interested on how to build the WASM build more easier with Swift tools.
I guess some tools exist to facilitate the final builds, but did not found it...
Do not hesitate to comment if someone experienced this before.
> So, if you want to build games using raylib, why not learn learning or use Swift for that?
Never ever worked for me. Imagine, you actually learned basic Swift and Raylib, now you want "advanced" features in your game like navigation/pathfinding, model loading, ImGui, skeletal animation (those are actually vital for gamedev). You realize that
- Navigation is only ReCast which is pure C++ library,
- ImGui has C++ API as first-class citizen,
- Decent animation with compression is only open-sourced by OzzAnimation which is pure C++ project.
For gamedev interfacing with C is never enough, half of ecosystem is built heavily on C++. Even C++ interop is not enough (see Dlang). Without all those libraries you are bound to make boring 2d platformers.
Same for Zig, Odin, C3 etc.
> ImGui has C++ API as first-class citizen
Dear ImGui via the C bindings is actually quite nice and not much less convenient than the C++ API (the only notable difference is that the C API has no overloads and default params).
E.g. here's a control panel UI (from the below ozz-animation sample) with the 'Dear Bindings' approach (using a custom 'ig' prefix)):
https://github.com/floooh/sokol-samples/blob/d8429d701eb7a8c...
Dear ImGui is a bit of an outlier for C++ libraries though, since it is essentially a C API wrapped in a namespace.
OzzAnimation is also fairly trivial to wrap in an (abstracted) C API, for instance I use this in some of the sokol-samples:
https://github.com/floooh/sokol-samples/blob/master/libs/ozz...
Implementation: https://github.com/floooh/sokol-samples/blob/master/libs/ozz...
...used in this sample:
https://github.com/floooh/sokol-samples/blob/master/sapp/shd...
...WASM live version:
https://floooh.github.io/sokol-html5/shdfeatures-sapp.html
TL;DR: quite a few C++ libraries out of the game-dev world are actually quite easy to access from C or languages that can talk to C APIs, mainly because the game-dev world typically uses a very 'orthodox' subset of C++ (no or very restricted C++ stdlib usage, no rtti, no exceptions, ideally no smart pointers in the public API).
Raylib has a C API though, and this is 'easy-mode' in any language (even without integrated bindings generation like Swift or Zig have - e.g. it's fairly trivial to write a bindings generator that uses Clang's ast-dump json file format as input and translates the API declarations into another language.
A more interesting question would be how well the C++ interoperability works that was added in Swift 5.9, does it work with all C++ headers, even headers that make extensive use of template code. Also how does Swift extract information needed for lifetime tracking, e.g. C++ APIs that return smart pointers and object lifetime ends on the caller's side. Does this only work for C++ stdlib smart pointer types, or are custom types also supported.
> A more interesting question would be how well the C++ interoperability works
They’re using it in their work on FoundationDB. Looks good, but has limitations. Swift can call C++ and vice versa, Swift classes can inherit from C++ and vice versa, but not for all code, and may need work adding annotations on the C++ side. See https://github.com/apple/foundationdb/blob/main/SWIFT_GUIDE.....
There’s a good video on that work from a few years ago that was discussed on HN in https://news.ycombinator.com/item?id=38444876.
For sure — that's where it gets difficult.
Show me a real C++ interop example. Does function, constructor and operator overloading resolve correctly? How about C++26 reflection?
Out of curiosity, how does the size and performance of the generated WASM compare to just compiling the same Raylib example from the equivalent C code via Emscripten? In other words, how much overhead does the choice to use Swift add here or in general?
Thanks for sharing it!
I might be interested on how to build the WASM build more easier with Swift tools. I guess some tools exist to facilitate the final builds, but did not found it...
Do not hesitate to comment if someone experienced this before.