Hello everybody, I'm here to post what I've spent the last two months working on: Solitaire!
I am aware that it already exists for this calculator, so this just more for fun and as a learning experience.

So far I have implemented:

▪Klondike with one card drawn per turn
▪Animations so that the cards move from one place to another when you move them.

I still plan to implement:

▪Other solitaire games starting with Spider, we will see from there
▪Saving the game and undo button
▪Better animations at the end of the game
▪Possibly an animated background by doing something fancy with the color pallet.

The code is available at https://github.com/GeometricParrot/Solitaire-CElection but this is my first project in C so it's pretty messy. If anyone has any tips that would be much appreciated as I am still learning.

For some reason that video won't preview, I don't know why. Permalink: https://github.com/GeometricParrot/Solitaire-CElection/blob/f3b4c6ee67d9d94c8222bf30651d054dea4b66cf/screenshots/record.png

I've made quite a few of these card solitaire games, so here are some tips:

The current size of your built binary is 24,335 B. My Calculation game is 11,876 B. These both have basically the same amount of art in them, so there must be an easy way to cut the size of your game pretty dramatically.

I think it's your graphics. Bundling blank_cardv2.png is the first obvious culprit. This is a 2.1 kB white rectangle. You can easily just draw it with a few calls to gfx_FillRectangle_NoClip(), gfx_HorizontalLine_NoClip(), and gfx_VerticalLine_NoClip(). The jack, king, and queen are symmetrical: you can flip sprites with gfx routines, so go ahead and keep only the top part. The king is the biggest, but all three can fit into a 35 by 26 pixel rectangle, saving you another 3.7 kB in assets. There's still a lot else you can do, but cutting the size of the binary by twenty-something percent is pretty nice IMO.

Why are target_y and target_x defined in struct Card? I have never needed a card to know where it is before. It's either somewhere on the table, in which case you know where it is when you make the call to draw it, or being animated, in which case (as far as I can see) you can store that information in struct Animation. The advantage here is that Animations are transient; you only have 13 of them, while you have 52 cards. So this reduces the runtime size of the program, and allows it to run on busier hardware without allocation routines failing. (Also, if life_remaining gets booted, it lets you make struct Card a one-byte bitfield: 2 bytes for suit, 1 byte for face-up/down, 4 bytes for value.)

For the cs_shuffle routine, you can do it more simply: Fisher-Yates is the algorithm to look at, and it guarantees a fair shuffle in 51 (possibly OBOE) passes instead of hoping for one in 255 ;)

Also, what is the actual point of the singleton struct State? Why do you need multiple States? This isn't a criticism or a suggestion, I just want to understand the design philosophy. I would probably have just put all these variables loose instead of bundling them and passing them around as an argument.

I am really looking forward to see you implement other rule sets! A "generic" solitaire game with dynamic rules (i.e. a menu to select which game) is something that I've designed and redesigned several times, but never released. I would love to see which approach you take!