Hacking Design Your Own Menu: Community Challenge!

[spinal_cord]

.... A windows8 style menu would be nice I think.


... hmmmm, does the dstwo devkit run on mac by any chance?

 

[Mars_x]

Alright, so far, the general consensus is that everyone wants smooth scrolling lists (and or grids too) with icons.

Now in order to do this, every icon would need to be cached ahead of time. This means that some limits will need to be enforced, such as the maximum number of icons per screen. This could be limited through a maximum number of files per folder, but too few files per folder is frustrating, and too many files eat memory.

Lets say we want to use 16 x 16 icons for files. Each icon in ram will use slightly more than 512 bytes. If we limit each folder to 256 files, thats a minimum of 128 kilobytes of memory used right there. Now, how slow do you think your sd card could load 256, 512 byte files? There are lots of factors to take into consideration here. Of course, increasing the icon resolution would increase the memory requirements, unless it is scaled upward in software, which won't look too amazing.

So make sure to keep such thoughts in mind with your menu designs as well. I only have 30 megabytes of ram to work with here, not the hundreds that other touch screen devices have.

I'm not saying these ideas are bad, its just we also need clever ways of applying said ideas within the design so that it appears possible within our hardware restraints.

I didnt know how much ram you have to work with, you asked users for concept and design.
Even if I knew your guidelines I would not know how to work with them in my concept, I dont know programming!

Anyways, there must be work arounds to every problem, how about the icons in folders are shown in a list instead of the grid?
Loading icon seems nice, is there a possible way to add that and load only the icons that are on-screen (plus a margin of 5, 10 icons) and
not ALL the icons at once?

 

[BassAceGold]

.... A windows8 style menu would be nice I think.


... hmmmm, does the dstwo devkit run on mac by any chance?

If you're interested in helping to code this project with me, you are welcome to do so. We can program all the core functions, and once that is finished, you can branch off the code to add in your own interface. That way, people can have a menu with all the newest features while having a choice on a menu design.

Also I'm not entirely sure the SDK works on Mac OS. What you can do, is install linux to a virtual machine, then have a shared folder between the virtual machine and your main os. That way you can do all your programming on Mac, and just use the virtual machine to compile the code.

I didnt know how much ram you have to work with, you asked users for concept and design.
Even if I knew your guidelines I would not know how to work with them in my concept, I dont know programming!

Anyways, there must be work arounds to every problem, how about the icons in folders are shown in a list instead of the grid?
Loading icon seems nice, is there a possible way to add that and load only the icons that are on-screen (plus a margin of 5, 10 icons) and
not ALL the icons at once?

I don't expect people to know what is capable of the hardware and what isn't, that's what I'm here for. It's just a friendly warning that if you have an idea about something, be sure to have a backup plan if the idea doesn't fully work out.

Just did some benchmarking with icon loading. It took 4.9 seconds to load 19 nds/nzip icons. Gonna have to do some optimizing I think.

 

[Rydian]

I wouldn't mind 2x scaling, nearest neighbor for icons, if that's the only choice, but of course screen real estate is an issue as well.

 

[The Catboy]

-snip-

That sounds like the official menu fused with iMenu

 

[2ndApex]

Since the EOS isn't being touched homebrew reset probably isn't possible right?

 

[Mars_x]

-snip-

That sounds like the official menu fused with iMenu

Maybe.
I dont know, I have not seen the official menu, but certainly the vision I have for the software is not the same as iMenu.
Animations look slow, graphics are butt-ugly (to me), I did not see any touch based functions and... I dunno, it just feels NOT
like the current mobile experiences. I can only hope my vision to be possible, but the truth is I dont know.

Just did some benchmarking with icon loading. It took 4.9 seconds to load 19 nds/nzip icons. Gonna have to do some optimizing I think.

What the ff... seriously? Damn thats a lot of time... but how? I mean, my AK2i loads icons just fine and I can scroll through folders filled with
dozens of icons in miliseconds, like really really fast...

 

[BassAceGold]

What the ff... seriously? Damn thats a lot of time... but how? I mean, my AK2i loads icons just fine and I can scroll through folders filled with
dozens of icons in miliseconds, like really really fast...

AK2i firmware probably uses the latest libfat and is probably more optimized than the version the DS2 sdk has. Or maybe they know some trick to load those icons fast that I don't know.


Been doing some more testing. The DS2 is very slow at opening files, 94% of the time spent getting the NDS icons is used by the fopen function rather than reading the data itself.

 

[The Catboy]

What the ff... seriously? Damn thats a lot of time... but how? I mean, my AK2i loads icons just fine and I can scroll through folders filled with
dozens of icons in miliseconds, like really really fast...

AK2i firmware probably uses the latest libfat and is probably more optimized than the version the DS2 sdk has. Or maybe they know some trick to load those icons fast that I don't know.

Fuse the sources!!!

I doubt that is possible though

 

[BassAceGold]

Well if someone wanted to update libfat in the sdk, its possible. It just wouldn't be easy. Maybe if enough people inform the Supercard Team of this bug in their SDK(poor fopen performance), they might correct it if possible.

 

[The Catboy]

Well if someone wanted to update libfat in the sdk, its possible. It just wouldn't be easy. Maybe if enough people inform the Supercard Team of this bug in their SDK(poor fopen performance), they might correct it if possible.

I say we all inform them, they can't ignore all of us.

 

[Terminator02]

So by inform them you mean we're going to need a translator again and send them the translated email. I don't remember any other "informing" method working.

 

[The Catboy]

So by inform them you mean we're going to need a translator again and send them the translated email. I don't remember any other "informing" method working.

Then we need a different approach to this

 

[ShadowFyre]

An XMB similar to the one of the PSP/PS3 would be cool~

Edit: LMAO that's what MENUdo is whoops.

 

[spinal_cord]

Been doing some more testing. The DS2 is very slow at opening files, 94% of the time spent getting the NDS icons is used by the fopen function rather than reading the data itself.

hmmm, by any chance, is seeking within a file faster than fopen? Would it be possible to create an icon cache file where the binary data from the icons is stored sequentially, using the short code from the header as an offset reference? Then you could just leave one file open for reading without having to recall fopen/fclose.

 

[Normmatt]

AKAIO doesn't cache any of the icons it loads them as it needs them. Must be that the libfat in the sdk is a bad version, in which case it wouldn't be that hard to update it, or better yet replace it with something like libelm which both wood and AKAIO use.

 

[BassAceGold]

Well if anyone is willing to update the fat library, please do! I just had a peek myself and it looks pretty scary with all those hacks to even get that old version running.

hmmm, by any chance, is seeking within a file faster than fopen? Would it be possible to create an icon cache file where the binary data from the icons is stored sequentially, using the short code from the header as an offset reference? Then you could just leave one file open for reading without having to recall fopen/fclose.

I've thought of that too, but the initial creation of that file would take a while to make.


UPDATE:
So I've improved the fopen times quite a bit now. The Supercard SDK fat library would search for the last cluster of the file to append to even when opening the file in read mode. So, now my fopen function does not do this.

The current benchmark of loading my 19 (2 nds, 17 nzip) file icons is 1.776 seconds (NZIP files take longer than nds files to load icons from). Not sure what the times are like on the nds with its fat library, but at least it should be quicker to stream load icons as needed now on the DS2.

 

[spinal_cord]

great news, even with a grid layout i cant imagine needing to load more than 5 or 6 icons at a time.

 

[VatoLoco]

cant wait to see how this turns out. BAGplug and iMenu are gonna be hard to top, heh.
i'll try to think of some stuff i'd like...already saw hb soft reset mentioned=)

 

[Boriar]

I want to see the skinning ability of MENUdo, the smooth and versatility of MoonShell2/Sakura, the super quality options of AKAIO and BAGPlug, and the homebrew compatibility of HBmenu. Also I think that the DSCovered (aka DSicion3) had a very good look (I really love slice my rom collection's front art), and the option to block some icons to bottom of iMenu (well mostly iOS option but..good anyway).

I know all that are well known ideas but if all are goods why not use they.

And something new: I really, really like to see a boot menu to let me use the kernel i want in any moment. I think that with this method will be more easy to test the new one without force to use a different flashcard.

Please BAG, what you think about last one?