Byte-sized Swift: Building Tiny Games for the Playdate

Community Showcase
,
21

What kind of performance difference would we see there? (I don't know if the Playdate has any benchmarking facilities.)

1 Like
22

This particular example doesn't have benchmarks, and runtime performance is not really to motivator for this particular case. It is more about code size. Performance of course does matter on the playdate. There have been some analyses of FPS, and I could see this helping there.

I do have a toy non-reference-counting linked list example (that I'm working on a write-up for to help with some of the ongoing reviews for ownership features). In that case, a simple benchmark of appending can result in a ~40% speedup vs use of a class-based list, and produces code that performs similarly to a pure pointer-based C example. Of course, this comes at a cost of only being singly-linked to preserve unique ownership (see the well-known rust article on linked lists for a very in-depth discussion of the tradeoffs with such things).

5 Likes
23

I love this and am having a lot of fun playing with it! In fact, it was what made me buy a Playdate. (I’m very glad I did because I absolutely love it! But that’s a different story.)

I noticed that some API areas didn’t have coverage in the overlay, including Sound. Then I re-read this from the original post: “It is not intended to be a full-featured Playdate SDK so please do not raise PRs to extend the Playdate Swift overlay to new areas.”

I won’t be surprised if it can’t be shared here, but I thought I’d ask: is there any guidance on when a full-featured version might appear? Is anyone working on it? Are there things they could use help with?

It looks straightforward to extend manually—though I haven’t tried yet—but I’m just wanting to focus my limited development time on useful things.

Regardless: thanks again, @rauhul and all involved.

1 Like
24

You could give GitHub - finnvoor/PlaydateKit: Create games for Playdate using Swift. by @finnvoor a try. There may be other forks with additional API coverage too.

4 Likes
25

I'll second the PlaydateKit recommendation. Development seems to have slowed some, but I'll bet pull requests would be welcome.

It's worth noting there is a new #dev-swift channel in the Playdate Squad Discord, and there has been a fair amount of discussion there.

1 Like
26

Just came here to say thank you to @rauhul and everyone involved in this project (Swift Compiler engineers, etc.). This has been incredibly useful, both for programming for the Playdate and learning more about NonCopyable types.

7 Likes
27

@rauhul So I have got this building on Linux kinda, mostly just replacing file paths. However there is one build hurdle and that is I can't get simulator builds to work on Linux. Real device builds build, I don't know if they work my Playdate doesn't come till tomorrow, but I get weird errors about unable to find these _eventHandlerShim _eventHandler. I was wondering if you knew the signifigance of these values and what is going on with them when they are exported in the final build command. Thanks and I love this project.

28

Fwiw, I'm getting the same error on Windows. I see in the original post that the armv7em triple came from the C examples within the Playdate SDK, but I'm seeing no reference to it in the Windows downloaded SDK. I'm also not seeing it in an extracted macOS SDK (albiet, on Windows) either.

Is the standard library for this target included with an Xcode install?

29

I can't speak to the windows swift.org toolchains but the macOS ones definitely have Swift.swiftmodule built in embedded mode for armv7em. The toolchains distributed with Xcode do not contain any embedded stdlib.

1 Like
30

You're correct - the Windows swift.org toolchains do not include the built module in embedded mode for armv7em. Before I try my hand at building the toolchain locally to include that, @compnerd do you have any insight into why this is the case? If not, no worries!

31

Building and distributing an embedded SDK would definitely be interesting. There are a few things that need to happen to make that happen. The first is that we need to have the requisite build.ps1 changes to build the embedded SDK as part of the build on Windows. Once that is complete, we would need to create a new MSI for the SDK to bundle that into the installer. A good example for this would be the android SDK. Finally, the bundle installer needs to be updated

As long as we are building the SDK only, this should be feasible. One tricky case is the cross-compilation mode (where we are building a ARM64 toolchain on X64). In such a case, the just built compiler is not usable for the runtime and we will need to do an extra compiler build to support building the runtime as we would not have a C/C++ compiler that can support that target.

1 Like
32

Hey @rauhul I read your blog with some interest. I was wondering if this approach is possible with some of these retro machines that are getting made these days like the Spectrum Next. I believe you can program with C on that platform using Z88?

33

It’s possible, but it would likely be a much larger lift because Embedded Swift hasn’t been fully ported to any 8-bit device. The first step would be making sure the LLVM backend for that architecture works (well enough). Next, you’d need to patch up the Swift standard library and compiler to play nicely. Finally, you’d build for that target triple.

I don’t think it’s an impossible project, but it’s definitely non-trivial!

34

Thanks for your response sounds complicated project. I know that rust might work on the mega65 a bigger retro like device that is 8bit. Anyhow an interesting thought.
Thanks!