I've been working for a while on making it possible to write Playdate games in Rust. I'm motivated to do this because I've become quite enamored of Rust; it has the performance of C but with compile-time features that make it harder to make mistakes with memory.
I've set it up as what Rust calls a no_std compilation model. I feel this is a much better fit to the limited resource of the Playdate than Rust with its pretty beefy standard library.
As soon as I get permission from both Panic and my employer I'll make it available for interested folks to play with.
I've been poring the C_API examples to Rust as a way of building out the wrappers. I've previously gotten Hello World and Life working in the simulator and on device, but Sprite Game has been a bit of a bear. Rust's strict ownership model makes sharing data between the main update callback and the sprite callbacks tricky.
This morning I finally got the Sprite update and draw callbacks into something basically works.
Next step is to finish porting the game. After that I think I'm going to make a Klondike solitaire game, as I've already written it once in black and white for a small screen and a rotary input device.
To the eye, the performance is the same, which is what you'd expect. Neither version does much work, most of it is done by the sprite system.
If one just leaves the Rust version running, it eventually slows down. I know that the Rust version does occasional allocations but so it might be a leak or heap fragmentation causing the slowdown. When the next SDK comes out with debugging I will be able to figure out what's causing the allocations.
As for sharing the code, I intend to as soon as it is ok with Panic.
Here is a snapshot of the crate and supporting tool. It is not for the faint of heart, as I've written no documentation. I fear it will only work on Mac, too, although Windows is a possibility in the future.
As far as logic goes, is it as simple as I imagine it would be? I've never tried something like this, and straight away I imagine you have your cursor with a state of either holding or not holding a card, and if it's holding a card, it simply checks for a valid or invalid placement of the spot under it when the user tries to drop it. And I imagine setting up a new game involves shuffling the deck and starting card distribution randomly (or, rather, randomly indexing a set sorted table I suppose).
Just curious about how this works overall, I haven't looked into it before.
Anyways, I'm really stoked to be able to try this out when I get my system. A solid solitaire game is a must have for a device like this Great work!
Pretty much that simple, although I'm limiting the positions that the cards will move to when held to legal play positions. On the iPod I found that made it a lot less frustrating.
I need to make the indicator more closely indicate the pickup position on the tableau. There also appear to be some navigation bugs moving backwards near the stock.
Feel free to try it out on Mac or device and I would value any feedback.
I also moved the work-in-progress Klondike game to its own repository, for easier testing and to allow me to write a desktop tool to solve games so I can pre-load the game with random number seeds that are winnable games.
Hey Rob! Been trying this out. I think as far as an indicator goes, you could use a much smaller triangle that points to the index on the card’s top left corner, or maybe you could also use a halo effect or border treatment on the topmost card that has the selection.
I also think that selection should work differently. I wonder if selection should work with up/down/left/right in a very literal sense, where pressing or goes up/down one card at a time in the stacks (excluding backside cards), until it selects the stock or Ace piles, and or to move across the bottom stacks or across the Ace piles or stock.
Great work!
or 
goes up/down one card at a time in the stacks (excluding backside cards), until it selects the stock or Ace piles, and 
or 
to move across the bottom stacks or across the Ace piles or stock.