Standardized Emulator Menu

[Tiptup300]

I can't wait till the Pandora is ready to get here, but there's one thing that troubles me. Each emulator will be made by different people so each menu will be drastically different with how they work and what all they can do. What I'm proposing is a menu system that each emulator would use to have a standard layout and overall functionality. They don't have to exactly look the same, but generally function the same. Here's a quick mockup of what it could look like.

More Examples:
http://img252.imageshack.us/img252/8820/delete2xl4.png
http://img253.imageshack.us/img253/7311/delete3ip2.png
http://img258.imageshack.us/img258/1518/delete4bz9.png

Note that the colors/shapes could be different so each emulator would still feel personalized.
Also note that the thumbnails are [obviously] fillers.

Also notice that you could have different views of the menu for each emulator, as long as it's all based on the same underlying structure.

Please comment.

 

[hells_dark]

I don't know what to think (it will be an additional work for the coders)..
But i like your mockups

 

[Bramrash]

It's not a bad idea, but people make these things for free, and from what i've heard, emulators are boring to port/code/dev for, and some people may like designing the menu's for their own emulators.

Still, I suppose it can't hurt to give the dev's the option of using a standard(ish) menu system.

 

[Tiptup300]

I'm saying build a library which handles all the menu programming. The emulator developers would just implement the library and customize it how they desire.

 

[Squidge]

The problem is people usually throw together a simple menu system whilst getting the emulator together and then spend time later on the system.

However, if someone built a library that could use a skinnable interface, I think it would be quite popular, as it would involve a lot less work for developers.

 

[Bramrash]

Did you make the menu for squidgesnes or did someone else do it?

 

[efegea]

Well, perhaps an idea is that all emulators must have command line parameters, so it can be launched by a frontend. This way the frontend can be skinned like your mockups (I liked them a lot). A frontend for each emulator or a multiemulator one.

 

[Squidge]

Did you make the menu for squidgesnes or did someone else do it?

Someone else did both the graphics and code for the SS menu system.

 

[skeezix]

Expanding on Squidges comment..

Most emus are 'quick ports' from someone elses emu; some are new emus from scratch.

In the case of a quick and dirty port, they're just hacking in whatever minimal controls and menu to get to where they want it. (ie: Not planning on doing more than necessary.. expect a lot of this early on, since it is natural and easy. Refine later.)

For a new emu from scratch, the menu is the least thing to get time.. usually no menu to start since its all bootstrap to get the emu going, then adding menus as needed. Much later, worry about pretty menus.. functionality is more important. People have limited time, and spending two weeks on a menu before you get the emu core working is silly

I suppose there is also 'well done port' a la Franxis MAME, where a lot of time is put into all aspects of an existing work.

Something to consider is .. many emus are very different. Floppy insertion, floppy flipovers, multi floppies; carts, tapes, keyboard or not, different RAM configurations, and so on. With so many hundreds of options across all emus, building them into one frontend makes the front end a mess and needlessly complex for the simpler systems. (This has been done before in the PC and DC and so on.)

Certainly, hundreds of times in the past its been brought up to make more common interfaces to the 'usual tasks', making and loading snapshots, and firing up the emu itself, and what buttons to turn up/down/off the audio while emulation running, etc.. but even then, the simple stuff people often expand or not on. ie: For my snapshot interface I like to create screenshots and various other info -- what disk(s) were in drives at the time of snapshot, what profile is being used, etc.. a lot more info than most. Making just a snapshot standard UI widget for others to use would make it a lot of stuff (plugins to show optional data and so on.. where most devs just want a snapshot list and maybe a screenshot, coding a good flexibile widget takes a lot of work; if its not all functional up front, devs will skip it and code their own since that is easy.) ie: Trade off the work to build the new general widget set, the work to use it for a dev,m versus doing it all your own which is both quick and easy.

Command line options with a common configurable front end has been done and works pretty well for 'general case' stuff too, but then its too fiddley for joe user (so others then supply them with config files and such ...)

All of this is why everyone just hacks their own front end.

Besides, am I the only one who likes the variety?

(UI 101 here -- no, you don't want every email app to work entirely differently; theres OS conventions to follow, things like 'Alt' highlighting menu hotkeys in Windows, and placing Help menu in certain places, and so on. Further you want general email app concepts to work the same, so that people don't need to relearn every single thing in every app.. Sure, of course. But when it comes to actual application functionality.. I like a little variety. This is why email apps use common frameworks, and common UI widgets and OS guidelines, et still are their own app with totally different look and feal, right?)

jeffsleepless

 

[emcp]

QUOTE
Besides, am I the only one who likes the variety?


yes,lol

anyway, i like the idea, but then theres practical issues to take into consideration

however i believe as a community, maybe we should get a thread together, do define what we want, i believe consistency is a must for a console (especially a handheld), not so much a PC

maybe have save dialogues, message dialogues, net dialogues
i never owned a G2PX, so i dont though if theres a settings category

but i think the os, should hold key user information, so it can be easily shared and adapted between projects

just the very basic nothing to defining

this would be a good community project, letting users design the "Console Made By The Community"
even those who cant code, would then have a say

ofcourse this would be just what the community would want, no-one is restricting the devleoper

all files must be available though, to make coding it much easier

however in terms of emus, i feel it may be a bit difficult to make a universal emu menu, ofcourse if you just have the layout the roughly the same, this would be the best option

 

[skeezix]

We beat this to death on the gp2x and gp32 so searhc for old threads, but the pandora is a new beast. Being a 'real linux' box, means a lot more can be leveraged so theidea has potential.

jeff

 

[WhiteFalcon]

Besides, am I the only one who likes the variety?

Hi Jeff

No, you are not, I too like the variety in front-ends as it helps the identity of an application.
Having all/most emulators with the same menu design would be boring and as has been stated,
a Gameboy emulator would really get by with quite simpler menu than an Amiga one.

Standardization can be useful, but too much of it kills the creative spirits

 

[parag0n]

I have used Wah!Cade before on my arcade cabinet to provide this.

It doesnt just work under mame however, you can add config files for a virtually any emulator.

http://www.anti-particle.com/wahcade.shtml is the website.

 

[mrsnature]

Well, perhaps an idea is that all emulators must have command line parameters, so it can be launched by a frontend. This way the frontend can be skinned like your mockups (I liked them a lot). A frontend for each emulator or a multiemulator one.

"must have"? Who's going to be the police? Maybe we need a penalty system to punish offenders.

Sorry, we don't want your free full speed psx emulator that you spent hours of your own free time on, it doesn't conform to our command line system! Shame on you! Your hard drive will now be erased.

EDIT:

Not to say it wouldn't be good if all apps and emu's followed a similar menu system, it would be good especially for new users, but you get what you get and can't be fussy when dev's are just developing these as their own hobby! I agree that if a good, flexible, menu library system was developed, developers are likely to use it, saving themselves time and effort, and keeping everything nice and consistant from a users point of view.

 

[Zenny]

I gotta agree, too many times i left gp2x to come back a month later trying to figure out the controls for each emulator, its such a headache. A skinnable frontend (one that can be customized really extensively by the developers) would be really great, it could have different styles like shown instead of just the one, but it should have the same functioniality no matter the style/design of the menu. Although this is probably greedy from the user point of view, for the casual users it makes life a hell of a lot easier.

 

[sterling976]

I kind of like the way mythgame handles this. You configure an entry for each emulator with a command line to launch it in fullscreen mode and point it at a directory that contains your ROM files. This automatically adds games into the menu. There's only one interface to deal with. Of course, if you have a large number of games on different emulators, this gets messy, but you'll have that problem even within a given emulator.

This approach does make three assumptions, if you want this to be a turnkey solution that doesn't require a lot of user intervention to set up:

1. Your emulator can launch a specific game in fullscreen mode from command line.
2. You have standard hardware/software for which the optimal settings can be prepared and either configured in the emu's configuration mechanism or specified when you invoke it from command line.
3. You have an mechanism in place for automatically creating a menu based on a standardized config.

The emu's author or porter has control over item 1, item 2 is a no-brainer: each Pandora's running the same hardware/software as any other (or you've customized your OS, in which case you don't need this solution), and item 3 sounds an awful lot like PXML, no?

PXML isn't 100% friendly to this approach, but it appears it would be possible to copy/paste your emulator config for each ROM, or better yet, for-loop yourself through your ROMs directory to generate a PXML file for each game. Even better, this won't require any additional coding -- it's all configuration of existing programs.

 

[jlebrech]

I think the emulators should not have main menus at all, and instead should accept a filename as an argument which will be supplied by the main menu of the console instead.

 

[cosam]

I think the emulators should not have main menus at all, and instead should accept a filename as an argument which will be supplied by the main menu of the console instead.

That's fine for an emulator of a "fixed" platform, like a console that only needs to be fed a ROM. For more complicated things, like an Amiga emulator for example, I don't particularly want to have to set command line options for which ROM I want to use, possibly multiple floppy drives, hard drives, different chipsets, configuration of above, etc, etc. I like the command line as much as (if not more than) the next guy, but when it starts to span more than two lines I tend to wonder if there's a better way ;-)

 

[Bramrash]

The button combo's for getting to and from the menu etc would definately benefit from having a standard, i agree with that wholeheartedly. But for some reason I think I also like the variety in the menu's.

Imagine DRMD without those floating circle blob things.... sounds like hell to me.

 

[skeezix]

I kind of like the way mythgame handles this. You configure an entry for each emulator with a command line to launch it in fullscreen mode and point it at a directory that contains your ROM files. This automatically adds games into the menu. There's only one interface to deal with. Of course, if you have a large number of games on different emulators, this gets messy, but you'll have that problem even within a given emulator.

This approach does make three assumptions, if you want this to be a turnkey solution that doesn't require a lot of user intervention to set up:

1. Your emulator can launch a specific game in fullscreen mode from command line.
2. You have standard hardware/software for which the optimal settings can be prepared and either configured in the emu's configuration mechanism or specified when you invoke it from command line.
3. You have an mechanism in place for automatically creating a menu based on a standardized config.

The emu's author or porter has control over item 1, item 2 is a no-brainer: each Pandora's running the same hardware/software as any other (or you've customized your OS, in which case you don't need this solution), and item 3 sounds an awful lot like PXML, no?

PXML isn't 100% friendly to this approach, but it appears it would be possible to copy/paste your emulator config for each ROM, or better yet, for-loop yourself through your ROMs directory to generate a PXML file for each game. Even better, this won't require any additional coding -- it's all configuration of existing programs.



See, theres the rub -- try ti 'simplify' the front end by making users hack in command line settings.

This is easier than using a front end that is ctrafted to make it easy for the user for the given platform?

IT _can be_, but it is not always possible.

Again, its the ST, Amiga, Atar 800 and other keyboardy or expandable machines that make it tough. Making users specify ROM type, RAM size, peripherals etc on command line is a nice to have, but it might just be better done inside the emu.

This is why I always say .. it is best to offer multiple ways; offer as complete a command line as you like (as a dev), and also have your own front end as you like. Then peopel can use generic front ends if they want.

This is how its always been and is exactly what you want

jeff