Byte-Sized Swift: Building Tiny Games for the Playdate
swift.org
swift.org
I had read a few of his devlog posts[1] from a while back and it's really cool to get an insight into his process. A while back I had also gotten into reading his updates on the process as he built his last game, Return of the Obra Dinn[2]. Only got 10 pages or so into the thread but again, his talent and attention to detail are incredible.
[1] https://dukope.itch.io/mars-after-midnight/devlog/261758/mar...
Effectively, there will be two bottom layers of Swift, and the lower one, “non-allocating” Embedded Swift, will necessarily be a more restricted compilation mode (e.g. classes will be disallowed as they fundamentally require heap allocations) and likely to be used only in very specialized use cases. “Allocating” Embedded Swift should allow classes and other language facilities that rely on the heap (e.g. indirect enums).
The Swift runtime APIs will be provided as an implementation that’s optimized for small codesize and will be available as a static library in the toolchain for common CPU architectures. Interestingly, it’s possible to write that implementation in “non-allocating” Baremetal Swift.I hope Panic is able to either retrofit or make a v2 with a backlight. I realized how low the contrast on the screen was after my cataract surgery and seeing details in some of the games becomes near impossible in less-than-ideal conditions.
(Also, more to the point of the article - kudos to Swift team. A nice language I hope becomes more widespread)
3 months later a package arrived from Playdate; as a thank you for the DIY work my BIL bought me one.
It's a very well designed and executed device, the crank handle is well used in many games, and it's nice to have a device that just does one thing and does it well. It can be a little tricky to play depending on ambient light.
Plus, it's the only way to play exclusive games of which there are many. My game YOYOZO was listed in Ars Technica's "Best Games of 2023" alongside several games by Nintendo.
Swift's inter-op story with C now is that most things are automatic, some things are configurable, and some just not. Clang supports multiple ABIs and calling conventions, giving control over optimizations, and linkers should work when the object files are valid. But tying it all together takes some detailed work in make. So the generality of clang and the linkers makes the potential reach large, but each new target combination will require some work.
I can see how individual developers might scratch an itch, but I'd be very interested to see if platform and library providers start supporting Swift directly. A bit of configuration could lower adoption costs, increasing uptake.
But where does that happen, and could that work be shared? Apple will continue to focus on Xcode, and most of this is out of scope for the Swift Package Manager. Swift support in CMake helps at the lowest level, but there's no dominant integration platform (like Eclipse was for Java) for contributors to share work.
Sharing experience is another thing. The blog author had internal experts at Apple available, but it's something of a black art to assess compiler work-in-progress and workarounds, and particularly to assess likely progress in a company that follows the first rule of fight club. That makes a blog entry of a successful port all the more valuable!
Not being much of a swifty, I didn't know anything about that API Notes thing. I like it a lot!
If you want to know more, plz visit my Twitter[1], or visit our website[2]
[1]https://twitter.com/madmachineio [2]https://madmachine.io
Anyway, the Playdate community has done some testing and the Swift code for the Life example, as released in the blog post, runs about 60% the speed of the C example it was based on.
So it seems the claim was an assumption that it must be performant because it's Swift, rather than the result of any comparison or testing. It looks like I was too optimistic :)