Quite a late first post!

This project began quite a while ago, but I wasn’t devlogging. So let me show you around.

My plan with Resin

When I started out with Hack Club’s Sprig, I couldn’t really bear the software limitations. I always thought RPI Pico is more capable than how it’s portrayed with Sprig.

While this Hack Club initiative is great, inconsistencies between the web simulator and real firmware (many games don’t work on the console) mixed with quite a poor editor made me wonder about a Python alternative.
Its primary goal - beating current firmware:

No differences between simulation and real firmware, ensuring code works everywhere
HUGE performance improvement
Updated API, making Sprig feel like a real game console
Multiple-file workflow with imports
Image-based graphics (instead of bitmaps)
Better launcher experience

What have I already implemented?

By exploring MicroPython and testing the speed I saw something incredible - a seemingly equal setup had shockingly smooth perforemance, even reaching stable 60-ish fps!

All thanks to these solutions:

Python handles calculations, C handles hardware access
Small framebuffer allocations within Python, C code handles displaying the pixels
Utilization of the DMA (direct memory access) chip - allows no CPU use for certain memory transfers, which doesn’t block game loop

In addition to this, Input, Rect drawing, persistent State store and general rendering now work flawlessly.

Out of screen objects are not rendered (culled), which also helps with smooth frame times. Sprig’s official colors are also transferred perfectly!

How did the development journey go so far?

Initial build setup was quite complex, as I’ve never made a MicroPython derrivative, so I had to carefully plan the architecture (to make Resin firmware build, include custom libraries, and have in mind publication to PyPI).

On top of that, the hardest part was getting hardware to register properly.

Screen requires some magic bytes to be sent to initialize. SPI bridge for communication made things easier (having to manage only a handful of pins), however getting it to render colors and do so in correct orientation was a nightmare.

Official repository was a great point for reference regarding to how hardware is configured and wired on the PCB, however I had to make my own research while implementing DMA chip framebuffer transfers.

The rest is pure python - when I implement the game launcher and write a small utility to make game transfers easier, I will finish defining the rest of developer API.

What’s next?

Resolving bugs, writing a launcher, and, of course, a simulator, so that anyone can develop games for Sprig without the real hardware. This way Resin can even become a choice for game developers and function as a standalone game engine!

Delta time for frametime-independent calculations and API guards to not overwrite important memory by accident are also one of my top priorities.

What you see below is a test Python file running - no C code for game’s logic. If you have a Sprig and want to help me test Resin, DM me on Slack!