PETI Update: Version 0.0.4 (and next steps)

Last Updated: 2021-10-31 09:00:00 -0500

Last Time Around, we talked a little bit about the hardware backplane and audio. Spoiler alert: that is now a solved problem. While PETI itself doesn’t use it, I’ve proofed the timing circuit and I’ll be ordering those boards eventually, which will be a good time to talk about that a bit more and implement it into the PETI software itself. Instead, I’ve been putting work into solving a problem with the main menu screen: drawing the icon-based main game menu, released as PETI firmware v 0.0.4.

Main Scene Menu Generation System

Implementing the main menu screen involved implementing a similar system of directive-enhanced printing seen in the printTextLarge_enhanced function; printTextMedium_enhanced. Unlike the large print function, the enhanced medium print just allows us to color-invert each 8x12 cell of the next. This is being used to facilitate highlighting menu options. (The scene_calendar_menu scene was also updated to use this).

With that taken place I created a pretty simplistic scheme where there’s now a new header file lib/menus/main_game.h, that defines three things we need to know:

  • an array of menu icons, identified as their character code in font8x12, in the order you want them to appear.
  • a matching array of scene addresses, in the same order, and
  • an integer describing the length of those two arrays.

Given that information the scene described by lib/scenes/main_game.c now does the following on each frame:

  • divide up the icons between the top and bottom frame as evenly as possible
  • pad strings to center those icons on either the top or bottom, and;
  • check an internal state variable (the cursor_position) to determine which icon to highlight.
  • check another internal state variable to see if we’re changing scenes.

Because of this structure it’s pretty easy to modify the menu without ever actually touching the main game scene. This is part of a philosophy of moving certain elements, desired to be easily modified, out of the more complex game code. It’s the same idea behind how species animations are defined.

The release of v.0.0.4 added the following menu icons:

  • a wrench for settings
  • a knife and fork for the food menu
  • a scale for the pet status menu
  • a smiling face for the games menu
  • a bug for the debug menu
  • a calendar, ultimately intended for a clock display screen, which directs to the calendar setup menu.

Most of these scenes currently point to placeholders that simply display a message indicating the button works. The debug menu icon sends you into the old demo mode. More icons will be added as more and more portions of the firmware become available.

Generalized Menu Generator

Several of these menu icons (and others planned but not implemented) will be leading to menus of a generalized nature. For example, there’s no fundamental difference between the logic of a food menu, a games menu, and the debug menu, other than what text they display and what scenes those options lead to.

As a result an outstanding work item is going to be to create general logic for creating those menus, likely using some similar configurable headers to what you see for the main game menu generator functions; an array of strings for the submenu names, and an array of scenes that describes those submenus.

Ideally this can be implemented in a way that maximizes not just code reuse between scenes, but maybe allows for one, general-purpose menu scene that simply takes as arguments its input data. This would minimize the impact on device memory.

With That In Mind: Localization

Several operations ago I moved several display strings to a file called lib/locales/en-CA.c and the associated header file. This was to facilitate localization of those strings. If someone comes along and wants to localize the pet to their language, other than probably needing to update the fonts a bit to support the characters they wish to use, they would just have to create the relevant locale file. Ideally, down the road somewhere, we’ll switch to compiler/makefile flags to pick which locale file to compile from.

Hell, if there’s room in storage we might even make language fly-selectable.

As a result of this those menu files should probably reference one of these locale header files rather than the menu file itself for display strings.

Up Next?

The menu system is not likely to be the very next thing created, because it’s not quite the next piece needed. The next run of code will all be geared toward gameplay implementation for the care of the pet. To my mind, what makes the most sense here for next steps is likely a status page that shows you the current condition of the pet.

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.