If you were interested in my last bit of alternative code-geekery, you may also be interested to hear that I've pushed that NerdKit Gaming code farther. If you browse the github repository now, you'll find that the game also includes a highscore board, saved in EEPROM so it persists across reboot. It also features a power-saving mode that kicks in if you don't touch any buttons for about a minute. Key-repeat now also allows the player to hold a button down, instead of pressing it repeatedly, in order to move the cursor multiple spaces.
You may remember that I left of my last blog post noting that there wasn't much left for the game until I could find a way to slim down the code to fit new things. So what allowed these new features to fit?
Well, I did find ways to slim down the code: I was right about making the game state global. But, I also re-learned a lesson that is at the core of hacking: check your base assumptions before fiddling with unknowns. In this case, my base assumption was the Makefile I imported from an earlier NerdKits project. While making the game state global saved a little better than 1k of space, changing the Makefile such that unused debugging utilities, such as uart, printf, scanf weren't linked in saved about 6k.
In that learning, I also found that attempting to out-guess gcc's “space” optimization is a losing game. Making the game state global had a positive effect on space, but making the button state global had a negative effect. Changing integer types would help in one place, but hurt in others. I'm not intimately familiar with the rules of that optimizer, so it felt like spining a wheel of chance choosing which thing to prod next.
You may notice that I ultimately returned the game state to a local variable, passed in and out of each function that needed it. The reason for this was testability. It's simply easier to test something that doesn't depend on global state. Once I had a bug that required running a few specific game states through these functions repeatedly, it just made sense to pay the price in program space in order to be able to write unit tests to cover some behaviors.
So now what's next? This time, it's not much until I buy a new battery. So much reloading and testing finally drained the original 9V. Once power is restored, I'll probably dig into some new peripheral … maybe something USB?
Post Copyright © 2011 Bryan Fink