Neo Myth Menu v1.1

[Conle]

AWESOME NEWS!!!!  

so, do sd cards work OK now? can you please show me a link in the IC2005 store the card that works?
that opens up a great convenience possibility , especially with the N64 Myth system where even 1gigabit could be small 

Yes , ChillyWilly is a beast  .

http://www.ic2005.com/shop/product.php?productid=41&cat=5&page=1

[keropi]

thanks! it is indeed a VERY usefull feature!

[ChillyWilly]

The Neo2-TF should also work, but I don't yet have one to test. I should be getting one soon, though. The Neo2-SD is the one I've done all the work with and works great. It also takes plain SD cards instead of micro cards.

So after 10' of thinking , i came up with this concept code :
http://pastebin.com/m5cff8031

It will also use EventLibrary ->
http://www.neoflash.com/forum/index.php/topic,5839.0.html

And maybe a simple configuration library for themes.

What do you think ?

Yeah, something like that for the GUI library. I think we should have four states: disabled, enabled but not selected, enabled and selected (you have navigated to it, but not pushed a button yet), and enabled and active (you press a button while it was selected).

As I mentioned before, we'd devote two palettes to the GUI - the first is fixed and has all seven grays the MD palette allows along with 8 other fixed colors like red, green, and yellow. Disabled and enabled-but-not-selected would have their cell graphics use shades of gray, with disabled being the same but darker gray. The other two states would supply a palette to go with the cells for their graphics, so enabled-and-selected and active could have nice 15-custom color graphics. I think that we should allow selected and active to also specify sets of cells to use in sequence for animation. Imagine the cells for the button making up like three or four frames of Sonic running. Not too big, but gives a really nice icons. Kinda like the penguin smileys on the board.
 

So most of the widgets will spend most of their time in the disabled or enabled state. One widget will be selected, and when you push a button will then be active.

The cells would be loaded from the current skin. So widgets would be primarily graphics based. Loading the skin would load new patterns into vram, then attaching the cell pattern names to the widgets. That way many features of a skin can be used by various widgets, and having the widget specify pattern names keeps the size smaller. So instead of drawing a widget, you just change four or six or whatever cell pattern names where the widget is located. So changing a widget from selected to active would just involve changing several bytes instead of several dozen bytes. We'll have a font as well for when regular text is needed. It'll be part of the skin so that people can have custom fonts as well.

[keropi]

the TF version should be better since it does not have the card come out on the top, like the SD version...

now I see that BOTH sd/tf carts have printed in the back that they are compatible with the NEO SEGA/SNES/N64 carts 

one thing to notice is that the TF cart supports only up to 1GB carts...

[ChillyWilly]

the TF version should be better since it does not have the card come out on the top, like the SD version...

now I see that BOTH sd/tf carts have printed in the back that they are compatible with the NEO SEGA/SNES/N64 carts 

one thing to notice is that the TF cart supports only up to 1GB carts...

I think that is just because when the page was made, 1GB was the largest size there was. These days, there's 2GB MicroSD cards, and 4 to 16GB MicroSDHC cards. I need to pick up a couple for testing. I'll pop over to NewEgg and put an order in for after xmas.
 

[DjoeN]

Great work!

Things keep getting better 

[Conle]

Yeah, something like that for the GUI library. I think we should have four states: disabled, enabled but not selected, enabled and selected (you have navigated to it, but not pushed a button yet), and enabled and active (you press a button while it was selected).

As I mentioned before, we'd devote two palettes to the GUI - the first is fixed and has all seven grays the MD palette allows along with 8 other fixed colors like red, green, and yellow. Disabled and enabled-but-not-selected would have their cell graphics use shades of gray, with disabled being the same but darker gray. The other two states would supply a palette to go with the cells for their graphics, so enabled-and-selected and active could have nice 15-custom color graphics. I think that we should allow selected and active to also specify sets of cells to use in sequence for animation. Imagine the cells for the button making up like three or four frames of Sonic running. Not too big, but gives a really nice icons. Kinda like the penguin smileys on the board.
 

So most of the widgets will spend most of their time in the disabled or enabled state. One widget will be selected, and when you push a button will then be active.

The cells would be loaded from the current skin. So widgets would be primarily graphics based. Loading the skin would load new patterns into vram, then attaching the cell pattern names to the widgets. That way many features of a skin can be used by various widgets, and having the widget specify pattern names keeps the size smaller. So instead of drawing a widget, you just change four or six or whatever cell pattern names where the widget is located. So changing a widget from selected to active would just involve changing several bytes instead of several dozen bytes. We'll have a font as well for when regular text is needed. It'll be part of the skin so that people can have custom fonts as well.

Okay  , i will design a quick test image soon to show you what i have in mind 

But you should better take care of the renderer.
Basically we're going to need a render function for rectangles & font.

[ChillyWilly]

Okay  , i will design a quick test image soon to show you what i have in mind 

But you should better take care of the renderer.
Basically we're going to need a render function for rectangles & font.

Make the mock-up and we can then see if we can't figure how we want to handle the GUI. I might make my own mock-up as well.

I'm thinking more about the skin providing the pieces needed than trying to render anything. Need corners for a raised button? Use the cells in the skin that correspond to those corners. Need the center part of a progress bar? It's in the cells in the skin. Just like the font provides cells that give symbols, the skin provides cells that allow us to make widgets and other things needed for the GUI. An ASCII skin would just make those pieces look like the current ASCII menu display.

[Conle]

ChillyWilly , what do you think about this :



-Window control is parent
-Tab contol is child of window control
-All other controls are children of tab control

Edit : The listbox should accept a custom void pointer and a callback so we can add instantly the labels without having to store the data 2times.

And another thing , the screenshot might not look well on a CRT monitor unless you select this text and the surface of the image is covered with the selection highlight color.

Uh and we're going to need a more generic name for the library.Open Retro GUI Library sounds cool.

O.R.G.L.

Some stats :
Widget | Render calls
Window | 5 : 1Fill bg color , 4 Lines(HL color)
Tab | 4 Lines + 4 Lines * tabs + text * tabs
Listbox | 4 Lines + 1HL cell , + text * visible elements
Progress bar | 4 Lines * 3(2nd pass -> fill and optional highliting)
Checkbox | 4 Lines  +- 1 small rounded polygon if checked + Label
Label | 1call
Image | 2Calls : Bind & Render
Button | 4Lines + FILL BG color(=tab bg color) + text

The group must be active of course.

[ChillyWilly]

Looks like a PC gui. Ever looked at a PSP, PS3, or XBox 360?



Plain version built into the PSP. Of course, you can then load "themes" that can make it look better/different.



That's what I want more than a PC gui. The wallpaper goes into one layer (B), and the crossbar goes into the other layer (A). Disabled widgets and enabled but not slected widgets would look like the plain widgets in the first pic - gray/white and plain. When you navigated to a widget, it would look more like the ones in the second pic - nice and colorful.

[Conle]

Yes i have both psp & xbox 360.
This should be much easier to implement.

[ChillyWilly]

Yes i have both psp & xbox 360.
This should be much easier to implement.

Not just easier, but it'll look MUCH better on the "small" 320x224 display. A PC gui really only works when you can do at least 640x480, and most PC guis now are geared toward a minimum screen size of 800x600. Trying to use them on a small screen looks ugly and cramped.

But the easier part is important: it makes it easier for people to make themes. It also makes it easier on programmers (even if that's just you and me right now). Easier on the programmers means less debugging.
 

[Conle]

Yes you are right   .
By the way , which image format is recommended for best possible results?

[ChillyWilly]

Given the MD, probably 16 color (not 16 bit) BMP.

[Conle]

Thanks i will do some tests soon  !