PETI Update: Version 0.0.5 (The Menus Update)

Last Updated: 2021-11-10 05:00:00 -0600

Considering I called this punch during the previous update, it should come as no real surprise to anyone that the most recent release of PETI code, v 0.0.5, is mostly about menus. Indeed, you could even go so far as to call it as the Menu Update. In this update, we’ve added the custom menu that displays the pet’s current status, as well as the all-important text menu generator, which will let us avoid making too many more special-purpose menus.

The Special Status Menu

As you may recall from earlier posts, PETI’s internal game state object controls, among other things, the current health of the pet, tracking details like hunger and boredom. Because I wanted this menu to have a graphical feel, its controlling scene had to be specially made specifically for this purpose, including features like bar generators, with which I had some prior experience.

If we’re being honest, this menu isn’t fully realized yet. There are some minor visual bugs to sort out, such as the leading zeros on the age display, and a few interpreters that aren’t actually implemented yet. There’s good reason for that, though - I’ve yet to fully implement or specify the objects they interpret, and I would need to do that before I can finish those interpreters.

The Text Menu Generator

PETI is becoming a balancing act really, really quickly. We’re averaging about 75-90% of RAM usage at any one given time. In fact, ever since I more or less exhausted the address space in font16x16 (the iconography font for the main playing field), I’ve been concerned to the point of paranoia over managing the usage of memory. Moreover, and fundamentally - I am lazy. I don’t want to implement several text-based menus, more or less from scratch, every single time.

So I built a generator, through which I could easily implement new menus by simply providing three details: an array of option strings to display in the menu, an array of special pointers to functions for each of those options, and an integer that gives the length of those two arrays (which should be the same). I made a simple implementation of this in scene manager for the debug menu.

Getting this working took a lot of doing, and I got a lot of help from members of the patron-only Clickspring discord, as well as members of the Arcana Labs community. There was a lot in this generator that I did not actually understand how to do properly in C, and now I understand those things, so overall it was worth it.

Next Steps: Slowing Our Roll

At some point in the past, even rather recently, I’m sure I promised I would be able to maintain a faster cadence on PETI for the immediate future. After all, we’ve knocked out a lot of the general problems in PETI. Most of what’s left is the occasional special function, and state manipulation. That is still true. In fact, even the development cadence increase is technically true.

What is less true is that the next version number, 0.0.6, will likely not be reached any time soon. Instead, I’m working on a branch I’m thinking of as 0.0.5r2. No major new features will be added, though ideally a few bugs I’ve noticed will get patched in the process.

What’s more important to me right now is a global refactor of the codebase. It’s pretty unweildy, for how uncomplicated PETI’s concept is. We’ve got dozens of includes mapped across four or five subdirectories of my library files, plus the entire codebase of TI’s pret-a-porter drivers for the device, plus the minimal device header files.

Stopping now for a refactor almost feels premature, but it’s chiefly justified through two main concerns:

  • I am fundamentally lazy, and Tapestry taught me my lesson about late-game refactors. Refactor early, refactor often.
  • Refactoring now will simplify both the codebase and its documentation. Above almost all other stretch concerns, I wish the codebase for PETI to be well-documented and easy for other people to understand, to the best of my ability. This is because of one of the stated goals of the project, namely that J Random Hacker, even J Larval Hacker, could pick up the codebase, a PETI device, and (if need be) a programmer, and start running with it. (In fact, more than one person has already implied an interest in obtaining development hardware for the device).

The refactor I’m talking about will chiefly target the following points:

  • Identifying and removing magic numbers from the code, which are mostly present in relation to display definitions and the number of rows or columns used on the display by certain elements, to be replaced with documented Defines
  • In addition, minor tidying of already-defined magic numbers, like Scene Addresses.
  • Fixing the DisplayFrame. Currently every scene instantiates its own DisplayFrame object. At about a hundred bytes a piece, reducing these all to one shared DisplayFrame object (as was the original intent) will reclaim a lot of memory.
  • Speaking of reclaiming memory, this is an overall goal. It is desireable to locate as many symbols as possible and move them into the PERSISTENT pragma, ie kick them into FRAM from RAM.

This refactor will probably also take longer than the last few updates. While it can’t be considered part of the refactor per se, the effort in general is also going to run parallel to a reshaping of the documentation, which frankly has lagged heavily behind the codebase, both in its public forms and in my private notes. It’s effectively the goal to have this finished by the end of the year, if not late January 2022.

PETI is a major project intended to design and construct a virtual pet from Open Source Hardware and Software, and to encourage others to modify and tinker with similar projects. If you would like to support the development of this, or any of the other projects I’m working on for Arcana Labs, and you wanted to show your support financially, your best avenue is via my Github Sponsors account or by making a one-time donation to Arcana Labs via or through other avenues detailed here. Github Sponsors also get access to a special patrons-only section of the Arcana Labs Discord Server, where we talk about the ongoing super-secret project.