HomeMenu
| This is an old revision of this page, as edited by MetaFight (talk | contribs) at 08:18, 4 April 2009. It may differ significantly from the current revision. |
| HomeMenu | |
| General | |
|---|---|
| Author(s) | MetaFight |
| Type | Library |
| Version | None yet |
| License | None yet |
| Links | |
| [[Demo application (based on Shiny Red Tank)|Download]] | |
| [[Google Code Download|Source]] | |
HomeMenu is a library written in C which provides a Big-N style Home Menu. It aims to be graphics-library-independent so it can be used regardless of your application's underlying graphics code/library. It also allows you to associate your own functions to events such as when the menu opens, closes, redraws.
It's coming along well but isn't completed yet. An up-to-date "To Do" list can be found on the SVN.
News
3 April 2009 -- A few small changes. Now the lib actually works with GRRLIB apps. I've updated the usage instructions (below). I'll update the SVN and the .zip asap. Next up: Learn how to use compressed textures.
MetaFight 03:49, 4 April 2009 (UTC)
1 April 2009 -- I put up a quick and dirty conversion to C up on the SVN. Preliminary testing showed no bugs. I would appreciate it if somebody could point out any big NO-NOs in the code since it was converted with very little knowledge of C.
Oh, and no, this is not an April Fool's joke :)
MetaFight 06:40, 1 April 2009 (UTC)
30 March 2009 -- I'll be busy for the next few weeks so I won't be able to work on HomeMenu much. Since a few people have contacted me about getting the source I thought I'd release it early. The source is still for the incomplete preview, but a full v1 release shouldn't be too far away.
Enjoy!
MetaFight 23:15, 30 March 2009 (UTC)
Installation and usage
Installation
- Copy all the .c and .h files into your project (make sure the .c are accessible as sources and .h accessible as includes).
- Add
#include "HomeMenu.h"where appropriate. - Add
-lasnd -lwiiuseto your MakeFile'sLIBS :=line.
Usage
- Call
HomeMenu_Init()to set things up. Its parameters are:int screenWidth-- horizontal resolution of screen.int screenHeight-- vertical resolution of screen.void* framebuffer0-- pointer to the first framebuffer.void* framebuffer1-- pointer to the second framebuffer (Currently assumes double-buffering).u8 framebufferIndex-- index to last buffer drawn to [0, 1].
- Specify graphics library with
HomeMenu_SetGFX(). Accepted values are:HM_GFX_GRRLIBHM_GFX_LIBWIISPRITEHM_GFX_FAILSAFE(which currently draws nothing).
- Specify sound library with
HomeMenu_SetSND(). Accepted values are:HM_SND_ASNDHM_SND_SDL(not yet implemented)HM_SND_NOSOUND.
- When you want to display the menu (when the user presses HOME), simply call
HomeMenu_Show(). In order for HomeMenu to be able to take a screenshot (used as the menu background)HomeMenu_Show()must be called before flushing the framebuffer.
Tip: If you have a callback set up for when the user holds down on the wiimote's powerbutton, add HomeMenu_Hide() to this callback to tell HomeMenu to relinquish its control of the main thread.
Tip: If your application relies on a timer, consider using the HomeMenu_SetAfterHideMenu(yourCallback) callback setter. This will allow you to update your timer (if necessary) before resuming your application.
Libwiisprite users
Currently, the pointers to the framebuffers and the framebuffer index are stored in the GameWindow object as private members. Shiny Red Tank got around this problem by adding accessors to the GameWindow class. Hopefully, if there is enough demand, the accessors will be included in the next version of LWS (go ask!). Here are my modifications:
| Changes to GameWindow.h |
|---|
/*** Add the following lines in the public section ***/
//!Get a pointer to one of the framebuffers
//!\return a pointer to desired framebuffer, or NULL if index is out of bounds.
void* GetFrameBuffer(u32 index);
//!Gets the index of the current framebuffer.
//!\return value of index of current framebuffer.
u32 GetFrameBufferIndex(); |
| Changes to GameWindow.cpp |
|---|
/*** Add the following lines within the namespace wsp block ***/
void* GameWindow::GetFrameBuffer(u32 index) {
if (index > 1 || index < 0)
return NULL;
else
return _frameBuffer[index];
}
u32 GameWindow::GetFrameBufferIndex() {
return _fb;
} |
GRRLIB 4.0.0 users
I think the same problem (as mentioned above) applies to you guys. Here are the accessors I used during my testing.
| Changes to GRRLIB.h |
|---|
void* GetFrameBuffer(u32 index);
int GetFrameBufferIndex(); |
| Changes to GRRLIB.c |
|---|
/**
* Get a pointer to one of the framebuffers.
* @param index specifies which framebuffer to retrieve.
*/
void* GetFrameBuffer(u32 index) {
return xfb[index];
}
/**
* Get the index of the current framebuffer.
*/
int GetFrameBufferIndex() {
return fb;
} |
Feedback
Please direct all questions and feedback to the discussion page.
Statistics
I'd like to have a general idea of how many apps use this library (once released, or even off the svn). If you use it, could you please add [[Category:Homebrew using HomeMenu]] to your application's wiki page? Thanks.
Potential Issues
Currently, when the menu pops up, it takes a screenshot of whatever is on the screen and then uses GX to render everything it needs. Since I don't know much about GX yet, I can't tell if this approach will interfere with other graphics libraries. I know it runs fine with libwiisprite, but I'm not sure, yet, how it will fare with GRRLIB or handrolled graphics solutions. My advice: call the menu when everything has been drawn to the framebuffer, but before flushing it.
Similar issues will present themselves with sound. The menu will (eventually) stop any sound playback when it is opened. I haven't poked around ASND much yet, so I don't know if there is a way to save a channel's state and then eventually restore it. My current advice: make use of the callbacks (before menu is shown, after menu closes) to backup/restore your sound data manually. Another option of for me to just pause ASND and not include sound in the menu.
Thirdly, I haven't looked into this much yet either, but wiimote settings (resolution, mode) are set when the menu is shown. If there is no way for me to programmatically find what the previous values are I won't be able to restore them when the menu is closed. My advice: use the callbacks to save/restore wiimote settings before and after showing the menu.
Changelog
30 March 2009
- Sourcecode released (Google Code SVN).
- Updated preview (Now with rumble and some sound).
22 March 2009, preview
- Not yet complete, but you can get the idea.
Thanks
- Thanks go to the folks at #grrlib.
- Thanks go to the madness at #wiidevot.
- Thanks to Dykam for code snippets.
- Thanks to drmr for his Wii Homebrew Cursors.