In the UK maker scene, Dr Footleg is a very well known face. From Liverpool Makefest to Pi Wars, the good Dr can be found with a plethora of Pi-based projects and a smattering of 3D printers. For Footleg's latest project his focus shifted to our new Badgeware boards, specifically Tufty 2350 and one idea jumped to the front of the queue... Asteroids.
Grab a Tufty 2350 and build your next great project.
We spotted his project over on Mastodon, and it intrigued us, so we had to reach out and ask him to tell us more. The project is a hardware abstraction framework. It enables games written for a specific device in MicroPython to run on any hardware. In his example, Footleg is playing the arcade classic Asteroids on a Tufty 2350 and on a PC running Python and Pygame. The game module has no hardware dependencies, so it can be used across devices.
Download Dr Footleg's Asteroids and save the galaxy!
But, what inspired the good Dr to run Asteroids on a Tufty 2350? Pure nostalgia or something else? He was happy to tell us more over email.
"I was inspired to port Asteroids to the Tufty2350 in part because it is a game that has a place in my heart. I've always loved the simplicity of vector line graphics as a display style and who doesn't love blasting rocks in space! But partly why it jumped out as the ideal game to run on the badge was the controls being simple. No need for a 4 way directional control pad or joystick. Just a pair of direction buttons, a fire and a thrust button. Perfect for the buttons on the badge."
He explains that he searched for a Python version as a starting point,
"...as I find I always learn more from someone else's code than from writing my own from the ground up."
In the end he based the project on Samneggs' Pi-Pico code as it has "nice vector object classes used to render various game elements from common code." Footleg decided to create a platform independent architecture as he already had experience. Previously he had written and extended a C++ RGB LED matrix animations library
I asked if he came across any challenges or "gotchas" while writing the architecture. The challenge was control, but not game controls, those were simple enough. The challenge to overcome was that the original game code was written assuming it had full control.
"it was full of time hogging loops where animation sequences were running. This did not fit well with the Badge OS philosophy where the badge was in control, calling an update method to advance the app code in very short time slices. I've spent a lot of time breaking up loops in the original game code into single frame updates. This requires storing state outside the loop so that each call to advance a frame performs one iteration of the animations in play and then returns control to the badge OS."
Footleg's hardware abstraction architecture is impressive and covers mapping graphics methods to draw pixels, lines, shapes, etc into "public methods on a hardware wrapper class". He also found that the representation of colours varied between graphics libraries and different platforms and that also required wrapping. Key events, button presses were also mapped. So pressing Up on Tufty 2350 and the up cursor on a keyboard are handled in the same manner.
The biggest technical challenge was making the architecture independent of specific MicroPython libraries. He explains.
"I had to write wrappers for timing and timer classes, to implement equivalents of getting 'ticks' since power on for a microcontroller, or clock microseconds since epoch in full Python running on top of an OS on a computer. I ran into the reverse also, finding Enum being supported on Python but not in MicroPython on the badge."
What advantages does this architecture provide to the end user? Footleg explains that " being able to write and debug code on a computer rather than on a small hardware device" speeds up testing and iteration. Doing so means he is able to set breakpoints, step through the code, line by line and inspect the variable values using a full IDE on his computer.
But, there were disadvantages. First was timing. Code on the computer ran much faster than on Tufty 2350 and other MicroPython devices. This forced him to introduce time based delays by measuring the time, frame by frame and then inserting a sleep of adjustable length to ensure the game plays the same on a range of different devices. Different devices have different screen resolution and this is where vector graphics are well suited. Footleg explains that game mechanics depends on the size of your screen,
"you don't necessarily just want to draw things proportionally bigger. It is much more fun to enable the additional screen area to be used for more game playing space. Space is BIG, so why not have bigger asteroid fields filled with far more space rocks?"
A big game area with the same number of asteroids makes the game too easy, so more asteroids were needed to provide the gamer with a challenge.
Dr Footleg is still working on the project, and his to-do list is quite long. One item on the list is to port the game to Presto, our 4 inch, RP2350 powered desktop companion.
Wrapping up our email conversation, we asked, "How do you see this project benefiting the wider community?" Footleg summed it all up rather well.
"I definitely see this hardware abstraction approach has benefits to the wider community, and plan to open source my code as I do with most of my projects. I develop these projects to contribute to the STEM education of young people which is a cause I am passionate about. I use similar approaches for my robot builds (e.g. My universal robot project provides a common code base for most of my robots, just dropping in a different hardware interface for the particular motor controller HAT in use in a build)."
We thank Dr Footleg for this project and for taking the time to respond to our emails. You can follow Footleg via his Mastodon account and you can see all of his projects over on his GitHub page.
Grab a Tufty 2350 and build your next great project.