Hierarchical menus are now working. Internally the menu system supports two types of buttons, “action” buttons and “menu” buttons. “Action” buttons execute functions when clicked via the use of pointers to functions. “Menu” buttons switch from one menu to another via menu pointers. Outside of the menu system there is a third option, the “back” button. This just uses the current menu’s parent menu as a pointer and creates a “menu” button using it. The easiest way to build a menu system is to define the menus first, then add the buttons afterwards. This means you’ve got all of your menu pointers ready for the buttons to point at. Some things I hadn’t thought of:
- Need to be able to put text onto the menus using the TextWriter;
- How can the menu system hold data like a life counter that will update when the variable updates? Make a pointer to the life data?
- Still need to do the pad integration!
- Need to handle the released sound.
Oh. Just tested the menu system in Mario Kart DS, and that uses immediate (click event rather than release event) menus. Bah. I’ll have to work in an option to set the menu event type.
Scratch that, I’ve taken out the release event system as the two are pretty much incompatible with each other.
Pretty much finished, now. I’ve integrated the pad, added sounds to the pad up/down events and tidied various bits and bobs up. The trickiest bit was adding sound (again). It turned out that I was trying to access the menu set pointer from the wrong place, which was throwing all of the sound code out, but it took ages to work that out. Uploaded a demo to Simian Zombie and posted it to the PALib forum for feedback. Pretty sure that none will be forthcoming, but we’ll see.
The binary files are at this link:
I haven’t done anything with the TextWriter yet, nor have I added animated buttons and backgrounds or transitions. That all seems a little superfluous at the moment. Oh, another thing I’ve added - “Quit” buttons. This is a new button type both internally and externally. It allows the programmer to detect whether the menu system has reached a point where it can be discarded and the program can move on. I discovered that I couldn’t run two instances of the slideshow class as well as having the menu system in memory - I think I ran out of RAM. The “quit” button lets me free up the menu system memory outside of the menu structure and use it for more important things.
Aha, a sudden solution! The TextWriter thing’s easy to solve. If I had a “lives” button, for example, that button just needs to run a function that will:
- Increase the current number of lives (wrap if limit hit);
- Print the current number of lives to the screen next to the button using the TextWriter.
I need to extend the menu class so that it can run a function when the menu is first initialised; that way I can print the initial value of the lives variable. The “B” button should navigate back to the previous menu.
“B” button wired up, and sound generation moved into the MenuSet out of the menus - this makes more sense, and reduces the size of the menu objects. Menu initialisation functions work - they’re essentially “onLoad” events. Fixed some poor decisions in the TextWriter, too. It now occurs to me that the TextWriter should be able to buffer the background, too. Doh!
I wonder if I should do unload events?
Thinking about it, I don’t think the menu system should reset the currently-selected option to the top of the list when you navigate to a sub-option/external function.