Talk:HomeMenu

Screenshot?

I would love to see a screenshot of this. Also, see my comments on your user page.--Arikado 22:38, 22 March 2009 (UTC)

I might make a screenshot later. I don't have time right now, but maybe tonight. The demo is small to download anyway. -- MetaFight 22:52, 22 March 2009 (UTC)

I'd like a screenshot too as my Wii is currently MIA :P - InfernoZeus 23:20, 22 March 2009 (UTC)

I just put a screenshot up. -- MetaFight 03:05, 23 March 2009 (UTC)

Just saw that, looks great! Not using an additional gfx lib is good as well - InfernoZeus 03:17, 23 March 2009 (UTC)

Support?

I'm willing to add rumbling to it whenever you release the source.--Arikado 22:56, 22 March 2009 (UTC)

Uncanny Similarity

Isn't this the same thing as The HOMEbrew Menu Standard Library? - InfernoZeus 23:08, 22 March 2009 (UTC)

Unlike me though, MetaFight is claiming to be using no additional graphics libraries (doesnt GRRLIB count as one though?)--Arikado 23:12, 22 March 2009 (UTC)

It doesn't use GRRLIB. I only mention them in the thanks because someone in their IRC channel helped me find out how to copy the framebuffer to a texture. -- MetaFight 03:04, 23 March 2009 (UTC)

Customizable?

How easy will it be for us to swap artwork, add additional buttons, etc. With your library (without really looking at the source)?--Arikado 11:33, 23 March 2009 (UTC)

Well, the point isn't exactly to make it skinnable, but, if somebody really wanted to, it's just a matter of replacing the textures and re-coding the hotspots. I might eventually release a set of standard menus (one with a manual button, one with a TOS button, etc). Right now, creating a menu consists of HomeMenu hMenu = HomeMenu::CreateMenu(); This might eventually be changed to HomeMenu hMenu = HomeMenu::CreateMenu(TOS|MANUAL|BALANCE_BOARD|ANY_OTHER_OPTIONS);. Hopefully, that way things will be somewhat customizable while remaining consistent (like in commercial games). So, in short, there's no direct support for pasting pink ponies in your menu, but is that a bad thing? -- MetaFight

I don't really see the point of customization. The home menu should have a consistent interface, since it is meant to be a standard interface across applications. If anything, it should be skinned on a per-Wii basis, possibly loading files from a special folder on the SD card. --Blooper (Talk) 23:08, 23 March 2009 (UTC)

I agree that it should be as standard as possible between apps. Your per-Wii basis idea is interesting. I might implement that later on. -- MetaFight 23:41, 23 March 2009 (UTC)

Possible real installation?

Would it be possible sometime to make a home-made Home Menu install itself, so that it would work in the real Wii Menu, in games etc? -- Mekuso 15:44, 23 March 2009 (UTC)

I'm not exactly sure if I know what you mean. Do you mean replacing the Home Menu in commercial games and applications with this one? I don't know too much about that kind of stuff, but I'm pretty sure that it's impractical. When I asked about Nintendo's Home Menu in #wiidev I was told that it wasn't actually part of the wii. It seems more like it's just a library included in the official SDK. As such, every game/app probably has their own bundled Home Menu, and replacing it would be impractical. -- MetaFight 16:10, 23 March 2009 (UTC)

C++?

On a scale of 1 to 10, how much does this library depend on being written in C++ (as opposed to C)? --Pinecone 19:23, 23 March 2009 (UTC)

2 * pi? I've never coded in C as opposed to C++, so I'm not sure. It's a class, but it only allows one instance to run... would that make it easier to convert to C? I guess now's a good time to ask if people would rather it in C than C++. -- MetaFight 23:38, 23 March 2009 (UTC)

Update: See below.

In C instead of C++?

Would people rather this be in C (instead of C++)? I'm taking a few days break from coding so I can catch up on school work, but when I get cracking again it'd be nice to know if I should convert it to C before continuing. Also, if the library is in C++, but accessing it is C-compliant, wouldn't that still be OK? Please leave your opinion below. -- MetaFight 23:44, 23 March 2009 (UTC)

I prefer in C because Wii Quizz is only in C. And i want to add the menu. Thanks ! --CashMan 07:04, 24 March 2009 (UTC)

It should be possible to make it work in both with a C wrapper http://74.125.93.104/search?q=cache:CGzHj8bh8AkJ:blog.eikke.com/index.php/ikke/2005/11/03/using_c_classes_in_c+using+c%2B%2B+class+in+c&hl=en&gl=us&strip=1 Agoaj 19:01, 29 March 2009 (UTC)

A pure C lib would be my preference.--Michael 22:43, 30 March 2009 (UTC)

I would also like at least a C wrapper :). Icefireicefire 04:53, 31 March 2009 (UTC)

I'd like it in C. I greatly prefer C over C++, so that'd be best for me. --SquidMan 05:59, 31 March 2009 (UTC)

Considering that the devKit is written for C, this makes the most sense. That will make it compatible with more homebrew, and as an added bonus should still be forwards compatible with C++ programs. Or you could just release two versions. Using a C++ wrapper for a C program would be quite neat I think, although I know very little on the subject and can't make a proper recommendation there. --Thegamefreak0134 07:05, 31 March 2009 (UTC)

Ok, it seems like there's enough of a demand for this to be in C. The next thing I'll work on is converting this to C. Thanks for your input. -- MetaFight 17:46, 31 March 2009 (UTC)

I just uploaded a quick and dirty conversion to C to the SVN. I don't know much about C, so this is where other people will hopefully come in and help point out any huge mistakes. Although it feels uncomfortably disorganized, I sort of like the library in C better. Thanks for the suggestion folks :) -- MetaFight 06:47, 1 April 2009 (UTC)

It's a charme! :-)

Hi,

I just had a look at your "preview" and I must admit, I am loving it. ;) First ist looked a bit big, but then I switched my Wii from 16:9 to 4:3 and compared it to that one. Wow! 8-) I like the idea that you are trying to clone Nintendo's look and feel. It's nice to have an interface for homebrew which feels polished. :) Hope you keep up the great work!

BTW, if you want to mimic BigN's style (besides the need to use other sounds ;)) the titlebar should "blink 'n' bing" when you leave the menu pressing the home-button again. Just a detail, I know. ;)

CU, Mario

PS: It is interessting to me, that your pointer seems to be far less flickery then the original one (same spot I am sitting). Is there some magic involved? ;) Or are you just ignoring the Wii's sensitivity-settings and set them to "full" for your needs. :)

Regarding the "blink 'n' bing": I know exactly what you mean! I'm already working on implementing that. It's referred to as "Hotspot activation animations/sounds" in my todo list. As for the cursor smoothness, that's purely accidental. I'm just using wiimote code from other people's examples. Any enhancements are not my work, but somebody else's. I haven't been able to test my menu on widescreen mode or in PAL video modes, so I'm not exactly sure what you mean about it being big. I hope to get some testers soon. Thanks for the positive feedback. -- MetaFight 19:36, 31 March 2009 (UTC)

Design Feedback

Good job on this. I think the biggest thing it lacks is some way to configure the library to the developer's needs. What I would implement is either enable(option)/disable(option) functions, or have your init function accept flags.

Some things I'd like to see configurable:

1. Since the library handles the exiting type events, it's going to be a hassle for some apps that need to clean up prior to the user leaving the app. You could return an enum that indicates what action the user took from your show menu function. I prefer the library to exit in some cases, so an option to choose who handles the exiting events would be useful. A callback would help but returning an enum would likely integrate better into existing apps.

2. The sound is tied to ASND. Users of other mixing libraries would have to likely shut there's down before calling show menu and then re-init their mixing lib after the menu is withdrawn. I would rather have a more flexible sound solution. One idea would be for the dev to register a PCM playback function, that would handle the sound. It could default to ASND. In case the user has muted the app, I think an option to turn off sound all together would be useful.

3. Since you're drawing using GX, you're going to have some issues with apps that either a) don't use GX at all b) apps that change GX settings that are incompatble with your GX drawing code. Currently, the library requires the dev to explicitly setup GX to the library needs. A more flexible solution would be to allow the dev to control who sets up GX and default to the library doing the work.

--Michael 01:58, 2 April 2009 (UTC)

First of all, thanks for the in-depth feedback. I'm very new to this kind of stuff and appreciate being pointed in the right direction. I mentioned in a previous post that I eventually intend on allowing the user to pass configuration flags in the Init function. I like the idea of Enable(option) Disable(option) functions too, and I don't see any reason why I can't eventually implement both :). Ok, on to your points...

1. I had originally planned on implementing a "ReturnToLoader" callback and a "ReturnToMenu" callback, making them both manditory. I sort of like the idea of ShowMenu() returning a value based on the user's action, but I am also of the mind that the library should be exiting the game. When designing the structure of the library I thought implementing an exit callback would be the least work for developers, since moving all clean-up code to a separate function should be pretty straight-forward. Also, it would avoid situations where developers accidentally mishandle ShowMenu()'s return value and, consequently, the menu behaves counter-intuitively.

2. Hrmm. This shows just how new I am to wii homebrew. I thought ASND was the only way to produce sound. This complicates things. I like the idea of registering a PCM playback function... I wonder, though, if all that trouble is worth a few ticks and boops. Maybe I should just remove sound from the menu altogether?

3. Once again, this shows my limited knowledge of wii homebrew. I was under the impression that ALL graphics in wii homebrew used GX. I was relying on the fact that, no matter how GX was set up, drawing 2D was always the same. I noticed you posted a few GX related tips for developers. I'll take a look at those when I get home later.

Heh, I hope you keep following my work since I think you could help me a lot! I'm interested in your updated feedback -- MetaFight 03:18, 2 April 2009 (UTC)

No problem on the advice, glad you found my input useful.

1. I think most of the users will be fine with the library code doing the exiting, and those that aren't can probably modify your code anyway, so from a practical view point, I think it's fine. To me, having the library exit is wrong because it disrupts the normal flow of a program.

2. There aren't too many. Another one being used is SDL_mixer (and SDL itself has an audio API). I wouldn't remove the sound. I would just make it optional, and on by default.

3. You can write directly to the frame buffer, and get nice results. Here's an example that writes directly to the frame buffer (it's a gamecube example, so copy over a Wii Makefile to compile). The reason I bring this method up, is it could possibly minimize some of the issues related to changing GX"s state, i.e. this method wouldn't affect any GX state. But, I don't think using GX is bad, you just need to document who sets up the GX state, and what that state should be (mainly the vertex data/format to use, which in your case is 2 f32 for position, 4u8 for color, and 2 f32 texture coords).

--Michael 22:31, 2 April 2009 (UTC)

Hmm, that's a good point about the flow of the program in #1. I will probably end up returning a value. I was also thinking about how to play nicely with other libraries and it hit me. I could use preprocessor logic to define how my library plays sound or draws depending on which other libraries are present. I'm pretty certain LWS and GRRLIB define something like __GFXLIBNAME_h__. That should be enough for me to figure out how to make my GX code play nicely with them. Since there aren't very many graphics libraries out yet I could code the behavior for each one. If no known library is present I could default to a failsafe mode which either wrote directly to the framebuffer (this feels icky to me) or requested the dev specify GX details such as pixel/vertex format (and other stuff I still have to look into). Unfortunately I won't be able to work on it much for the next two weeks. I can't wait to implement these ideas, but I guess waiting gives me the benefit of being able to consider other people's input! Thanks again, MetaFight 02:00, 3 April 2009 (UTC)

Testers

Please leave your information in the list below. Include whether your PAL or NTSC and if you have widescreen or not.

• Example Name, you@me.com, NTSC, widescreen
• Roboprez, roboprez0@gmail.com, PAL, widescreen
• EliSherer, eli_sherer@mail.co.il, PAL, widescreen
• Kupo, kuporeleases@thegame.com, PAL, widescreen

multiple definition of

got multiple definition (using devkitpro 21 and libogc 1.8.5)

linking ... boot.elf main.o:(.sdata.HomeMenu_dimAmount+0x0): multiple definition of `HomeMenu_dimAmount' HomeMenu.o:(.sdata.HomeMenu_dimAmount+0x0): first defined here main.o:(.sdata.HomeMenu_fadeRate+0x0): multiple definition of `HomeMenu_fadeRate' HomeMenu.o:(.sdata.HomeMenu_fadeRate+0x0): first defined here main.o:(.sdata.HomeMenu_hoverZoomLevel+0x0): multiple definition of `HomeMenu_hoverZoomLevel' HomeMenu.o:(.sdata.HomeMenu_hoverZoomLevel+0x0): first defined here main.o:(.sdata.HomeMenu_activeZoomLevel+0x0): multiple definition of `HomeMenu_activeZoomLevel' HomeMenu.o:(.sdata.HomeMenu_activeZoomLevel+0x0): first defined here collect2: ld returned 1 exit status make[1]: *** [/usr/local/src/wii/boot.elf] Erreur 1 make: *** [build] Erreur 2

I've solved this by copying from HomeMenu.h to HomeMenu.c

const u8 HomeMenu_dimAmount = 96; // amount background is dimmed when menu is open;

const f32 HomeMenu_zoomRate = 1.01f; // Rate at which buttons zoom (orders/sec)

const f32 HomeMenu_fadeRate = 2048; // Rate at which top and bottom bars fade (256ths/sec)

const f32 HomeMenu_hoverZoomLevel = 1.07f; // Level to which a hovered-upon button zooms

const f32 HomeMenu_activeZoomLevel = 1.04f; // Level to which an activated button zooms

and removing there assigments (i.e.= xxx;) in HomeMenu.h

TheDrev —Preceding unsigned comment added by TheDrev (talk • contribs) 16:07, 8 January 2011 (CET)