unified menu for emulators

[skeezix]

Raine is an arcade emulator, and is not related to MAME. (MAME is not the first nor only arcade emu, just the most well known.)


As to a unified front end, not something I'd work on right now; I do my part of the pandora firmware and a half dozen of my own projects (new games, new applications, various ports, various devices), and have a kid and wife I get asked to help out on a project every other day so I can't sign up to many, my plate is over-full for 15 years straight


And I also don't mind - even like - each app having its own quirky UI; a unified one would be fine, but distinct ones are also fine. As long as they work and are clear, its fine by me. (Some _conventions_ are okay, but I look at it like adopting a unified UI often means many apps having the least common denominator, and it ends up being a lot of work for emu devs and porters who don't have a lot of interest in it. This has come up many times on many platforms over the many years emulation has been around, and usually it gets added in later by the non-core devs, so certainly could happen here too.) But in my brain, we like our old machines precisely because of their differences -- ST versus Amiga, C64 versus NES and Atari 2600, etc. When I wrote my own ST emu, and in various ST emu ports and hacks over the years, I built ST-like UIs.. a unified one would make it 'easier' for adopters from other emus, but it would take away all its character too. So its some of this on the left (easier, more consistent) and some of that on the other (less distinct). In the end, I'm too busy to worry about it


jeff

 

[SNESFAN]

That's cool, I apperciate the reply, id like to see it but I will not invest anymore thought into this. Just like anything its debateable but it appears those who have the skills to do this (much like other projects that don't see much support) the ones with the skill will have moral objections to the project. Those in support would lack the skill to do it properly. I just thought my (unoriginal) idea might help the platform from a newcommers perspective exactly as you stated.


I truely understand you being overworked and too spead out, don't feel bad on not taking it up. I am also vested into other projects and real world stuff, so I feel your pain.

 

[skeezix]

You can keep gabbing about it -- if a coherent UI design can come about, that could be a good first step (and chatting never hurt anyone.) I or anyone can help with noting what discussion topics have what sort of complexity/dev requirements.


ie: From a dev perspective its a question of .. is it a _frontend_ that invokes an emu, in which case the 'cost' to the emu dev is relatively minor, provided the emu supports a halfway useful set of commandline options. ie: Your 'interface' to the emu is command line, and you try to get the emus to have a consistent commandline, or at least a consistent command line feature set even with different option syntax, and make the frontend deal with it.


Or if the UI is built into the emus, then suddenly its not something that can be codede by one person and handed to the emus, you need buy in .. ie: the interface is at the code level, and it has a much higher 'involvement cost' to the emu devs, and also problems with updating either side over time.


A frontend is much easier for all parites to build, but of course is limited to what it can do -- pick a few common options and hand them to the backend; you still would have inconsistent UI 'in emu' (ie: pause menus, etc.) A common API that does 'menu stuff' that emu devs could use could save time in one hand (dev can use the API instead of rolling their own) and cost time (rolling your own is very easy for a simple menu, maybe supporting this conjectural one is a lot of work.)


So this is a pragmatic and real up-front design question -- what we devs call the 'scoping statement'; what is your goal, and how far are you going? (Noting that when designing this you have to decide not only based on what you want to do, but konwing if you go too far you nmight make it so no one will touch it. You probably have to find a middle-ground.)


After that question, you have a scope -- if you're 'just' doing a frontend, it limits what you can do and what you need to talk about, versus doing an API for a GUI.


Your scope should probably include discussing what machines are in and which are out -- 8 bit cart based machines, or 8/16 bit gamning platforms, or .. etc.


If you can't get 3 or 4 other people into the discussion, theres not enough interest to continue; if you can, the questoins aout shoudl keep you busy for a few days/weeks


jeff