Gmenu2x V0.5 Released


I gave it a go yesterday (for the first time might I add) and I found it to be a great alternative to the default firmware interface. Thank you very much, I'll be sure to make good use of it from now on :)

- Alex
 
here's a good suggestion....

how about the ability to move the icons about? this would be a valuable addition to the menu system as at the moment ive not got the icons in the way that i would like them to be displayed on screen...

thanks :D
 
not very easy to do though... also it will be more tidy the way it is...
 
subcon959 posted on Sep 13 2006 at 11:51 AM said:
Is it possible to get rid of the text for the sections and just have the icons?

I think you can ... just 'rename' them, with no text.
 
Last edited by a moderator:
TelcoLou posted on Sep 13 2006 at 05:57 PM said:
subcon959 posted on Sep 13 2006 at 11:51 AM said:
Is it possible to get rid of the text for the sections and just have the icons?

I think you can ... just 'rename' them, with no text.
I mean the sections in the top bar. I assumed not since the text is taken from the folder names, but it would be nice if there was some way to make them a bit different from the other icons. Maybe a different font if removing the text isn't possible.
 
Last edited by a moderator:
GMenu2X v0.6 is coming soon.
I implemented really a lot of things and thanks god I didn't start working on the filebrowser 'cause this project came up and it seems good enough to be used from gmenu2x.

One of the things I implemented is a builtin selector-like feature. It's really handful for me but there are too few emulators that allows passing a rom as a parameter. I'm currently testing it with race! (neogeo pocket) and it works fine.
It features also screenshots for the roms.

Of course there are emus that have a good interface and wouldn't need something like this anyway. But there are others such as PicoDrive, gp2xengine, hu6280 ecc... that could take advantage of this.

I'm probably going to hack some emu to add this support (shoudn't be too hard).
I still think that emulators should have separated frontends (look at gngeo2x+rage2x) but I know that sometime this would not be the best solution...

What are the emulators that can launch directly a rom from a parameter?
The only ones that I'm currently aware of are race!, mame and gngeo2x.
 
Last edited by a moderator:
Ryo posted on Sep 14 2006 at 11:39 AM said:
GMenu2X v0.6 is coming soon.
...<SNIP>
I'm probably going to hack some emu to add this support (shoudn't be too hard).
I still think that emulators should have separated frontends (look at gngeo2x+rage2x) but I know that sometime this would not be the best solution...

What are the emulators that can launch directly a rom from a parameter?
The only ones that I'm currently aware of are race!, mame and gngeo2x.

Glad a new version is coming, and glad you also think that JyCet's browser would be an almost ideal companion to Gmenu2X!

As for emulators which support commandline... Ones I'm sure about are:
GPFCE (NES Emulator, it also has various comandline options to swap NES buttons, and show FPS)
...and I think you have covered the others really...

Some of the application have commandline support... I think PrBoom can load a specified WAD from commandline, which might be handy.
 
Last edited by a moderator:
Ryo posted on Sep 14 2006 at 10:39 AM said:
GMenu2X v0.6 is coming soon.

One of the things I implemented is a builtin selector-like feature. It's really handful for me but there are too few emulators that allows passing a rom as a parameter. I'm currently testing it with race! (neogeo pocket) and it works fine.
It features also screenshots for the roms.

If emus already have menus and selectors why add another? It seems kind of redundant to me, especially if it loads the extra code everytime even if not used. I don't see the problem with selecting an icon in the menu to load up "Rage2X" or "Selector" in some emus. How much bigger will the menu get with all of these extra features? How much longer does it take to load up now? Is the menu more sluggish and will it eat up extra RAM that may cause some emus or memory hungry apps to not work? Will GnGEO load from the SD more frequently causing more pauses during games?

It may just be me but adding alot of bloat and slowing things down to add tons of features would be counter productive. It may be nice to have a "lite" clean and mean version of the menu without all of the fluff and loads superfast.
 
Last edited by a moderator:
As I recall the selector/browser was going to be a modular addition to GMenu2X... so basically nothing to worry about.

Emulators maybe have their own menus, but they really should have commandline rom loading facilities. For the simple fact that it would let you do simple things like configure a certain rom extension(or possibily rom directory?) to be loaded in a specific emulator, just by clicking on the rom file in the "browser".

I also think that a single selector is a better idea than each emulator having it's own selector, since it would take up less space on the SD card.
As for memory being an issue... gmenu2x terminates when it launches an application. I would imagine that the selector feature would be a tightly integrated module that would provide the functionality of "selector" so basically exacution would happen like this.

-pick application which uses selector as a frontend.
-gmenu2x quits
-selector module loads
-pick rom for emulator
-selector module quits
-main emulator runs rom
-quit emulator
-selector module is relaunched
etc...

EDIT: Please note, the above is just how envisage things to work, obviously I'm not Ryo and cannot know how he is planning to tackle things.
 
The selector is not modular, is builtin but I am 100% sure that it doesn't add loading time or memory usage.

I don't use new resources when starting the selector, the background is the same, icons are already used in the resto of the interface, also the code relevant to the selector is called only when you start it. There are no resources taken for the selector at startup.

I preferred to implement it builtin because it allows to quickly bring up the selector and eventually to return as quickly to the main interface if you change your mind...

The size of the executable is basically the same and if the loading times have increased it's not because of the selector (they may have increased because gmenu2x now starts the services such as samba, inet etc.. but it does it in parallel so it's not a big slowdown).

Why I think that a separated frontend and commandline support is a general better idea?

Because it allows another developer to implement a better interface than the one builtin the emu (sometimes emus are not opensource and you cannot modify the interface) also allowing other users to choose which interface is best for them.

Because it brings consistency (in my opinion the biggest advantage). It's much more user-friendly having a single interface for all the emulators.

And there are other advantages that I can't recall now :p
 
Ryo posted on Sep 15 2006 at 09:19 AM said:
The size of the executable is basically the same and if the loading times have increased it's not because of the selector (they may have increased because gmenu2x now starts the services such as samba, inet etc.. but it does it in parallel so it's not a big slowdown).


Does it always start those services? If so maybe have an option so it doesn't have to. I never use those things so no use having them running and maybe slowing down emus or apps. Maybe this is why i get an occasional annoying screen flash when in emus and games. I say if you don't need to dont run stuff in the background, it may just cause problems. I know those things are nice for devs but 99% of users don't use them most of the time.
 
Last edited by a moderator:
As PokeParadox said, we are talking about something that is only implemented in the version I am actually developing.
And for disabling that, gmenu2x only starts the services that are actually configured to start in the original frontend. So if you were not starting them with it, they won't start with gmenu2x.
 
Fantastic work, mate. This menu is so slick. People are so impressed when I show off the device.

Are there plans to make the TV out work correctly? It made a nice pattern on my TV when I tried it but it was almost impossible to use that way. Or is the solution to use the other TV Out application (if so, how does that work?)

Thanks again,

Mac
 
Macguyver posted on Sep 15 2006 at 04:37 PM said:
Fantastic work, mate. This menu is so slick. People are so impressed when I show off the device.

Are there plans to make the TV out work correctly? It made a nice pattern on my TV when I tried it but it was almost impossible to use that way. Or is the solution to use the other TV Out application (if so, how does that work?)

Thanks again,

Mac
I ran Oldplay TV out, exited it, and the menu was perfect. Weird...
 
Last edited by a moderator:
Macguyver posted on Sep 15 2006 at 10:37 PM said:
Are there plans to make the TV out work correctly?

Well, I had a lot of trouble trying to actually understand why it doesn't work.

The good news is that I finally found out why!
The bad news is that I don't know how to solve the issue. (actually there's something that I want to try)

The problem is connected to the autorun feature and to how the original frontend activates tv-out.
What I found is that if you have autorun enabled, after activating tv-out the gp2xmenu launches autorun.gpu but to actually activate tv-out correctly, it expects to relaunch itself and not gmenu2x. (don't know why)

Try disabling the autorun or activating tv-out without the sd inserted and, only after that, try to manually launch gmenu2x (launch autorun.gpu) and you'll have gmenu2x with working tv-out, which means that gmenu2x has no issues with tv-out.

PSyMastR posted on Sep 15 2006 at 11:15 PM said:
I ran Oldplay TV out, exited it, and the menu was perfect. Weird...

This just proves what I was saying...
 
Last edited by a moderator:
Back
Top