[PandoraRox]

Hello, my name is PandoraRox, and I have an idea. I realized early on that the Pandora will have many emulators, with inconsistent menu systems and control mapping, and I decided that there must be a better way.
Thus I came up with this type of hierarchical menu system, and I think that it will make gaming on the Pandora more intuitive and beginner-friendly.
Here is the first picture:

As you can see, this menu system shows the different video game brands. you can scroll through the logos with the analog stick or control pad. The parts that move are the logos. There is also a splash screen for each manufacturer. You can select with the select button.
If you click on Nintendo, it shows this:

As you can see, it shows a list of systems, both console and handheld, to choose. You can select up and down. It has a splash screen, a logo, and maybe a description could be put in place.
If you click on Nintendo 64, it shows this:

It has a list of games, and you can scroll up and down. The game starts up in the background, showing you how it works. There is a logo and there can be a description of the game.
If I click on Mario 64, it shows the game:

You can control the game and bring up settings.
So in 4 clicks, you can get to any game on your machine. I think that it would bring a level of usability to the Pandora that may not be found in regular consumer devices. Now, I am not a coder. I am presenting my idea with hope that this community will be able to do what I can't. If someone does decide to do this, I will be happy to provide any ideas, images, or help with the design of the menus that you may need.

[Squidge]

Whos going to create the icon and background for every single game, or are you going to have some default (generic) icons and backgrounds, which means you have then include text to make it readable? If so, then you could have a lot of wasted screen space for some systems where people don't want to create hundreds (thousands on some systems) of icons and backgrounds.

Secondly, where are the options for the various emulators going to be, eg. frameskip, etc?

[PoisonedV]

hyperspin-fe.com
its basically this exact thing, but more eyecandy, and on the left side instead of the right.
it has almost all NA-releases for NES, and many for other consoles, too.
unfortunately, it requires a lot of configuration. I don't use it because I don't feel like renaming either my roms, or renaming every single image. unfortunately, the lists they use on hyperspin don't use official romset names, except for the MAME wheel where its mostly focused atm.
so i think this would be a good idea, make a sleeker, less bloated, frontend.
if any dev does this, just give the specifications and im sure there will be a flood of content

[PandoraRox]

in response to squidge, as I said the game runs in the background, which takes screen space, and there would be some type of logo or custom icon, there could be a default icon for series if there is no logo. As for the options (button mapping frameskip) i think those should go within the emulator, but be brought up by the frontend (more unified). Of course, you could leave all of that to the emulator itself (without the frontend) and save a lot of trouble.

in response to PoisonedV, wow, that makes mine pale in comparison. But looking at the videos, i'm not sure whether it could be ported or if it could, work properly. So I agree with you that a less bloated frontend would do well on the Pandora. I think that there could be something to name the ROMS like when you import a CD into iTunes. It finds the name (off the internet) and names that file. Do you want me to post the specs for a dev? If so, which ones?

By the way, i'm really sorry about the quality of the photos. I had to make these shots in word.

[fusion_power]

I would be more than happy if all the Pandora Emulators would have a simple and clean menu System like "Picodrive" onto the GP2X has.

You too?

This post has been edited by fusion_power: 25 October 2008 - 08:33 PM

[PandoraRox]

I would be more than happy if all the Pandora Emulators would have a simple and clean menu System like "Picodrive" onto the GP2X has.

You too?

You bet. I just think it would be useful to have many other emulators, and this is pretty simple and clean.
Total Internet High Five!

[Squidge]

Since the Pandora has Wifi, we could even go as far as when you select a brand,system and game, the program checks the web after a certain delay (to ensure it doesn't try to download loads of data when you spin through the items) to see if theres updated artwork for that, and download if so. This way, you could just download the main app and it would download all artwork on demand - No need for someone to post they have created artwork X and to download it at Y.

[jakewastaken]

Since the Pandora has Wifi, we could even go as far as when you select a brand,system and game, the program checks the web after a certain delay (to ensure it doesn't try to download loads of data when you spin through the items) to see if theres updated artwork for that, and download if so. This way, you could just download the main app and it would download all artwork on demand - No need for someone to post they have created artwork X and to download it at Y.

Now we're getting somewhere. I wasn't looking forward to constantly updating screenshots at all.

[skeezix]

I hate to say it .. but please check the other discussions; for one, this has come up on pretty much every console for the last decade, and for the other, we've discussed it to death on the gp32, ghe gp2x, and are currently discussing it in a few threads for the pandora

Its not a new idea, it always has been an interesting idea, and it is often full of pitfalls (especially for machines that have a complex set of options, such as an Atari 800, Amiga, ST, DOS machine, and so forth.)

In the end, if someone made a simple API that managed all the GUI elements, so porters/coders could just adopt it, it'd probably take off. But the peopel who are desired to use such a thing, are busy working on their ports

jeff

Edit; sorry if that sounds cranky .., I've not had a good sleep in over 19 months so I am a little cranky sometimes

To wit ..

Firing up an emu with a ROM-path (say) may work well, assuming they all honour a simple common command-line (say), or at least the front end has a config system sufficient to detail the launch of each app. Showing screenshots and such for the roms is hard (mapping them back to useful pre-screenshots, or at least a standard for the emus to export screenshots the front end can use.. form savestates or whatever). The larger problem is for any machine with any form of configuration .. while in the past we had performance issues so SNES may or may not need transparencies on and off and so on, the panda should be able to handle much of the old school emus no problem. That issue still applies to newer machines probably, so the front end shoudl need to handle a lot of emu- and platform- specific options. ie: Some PSX emus may offer some options that others do not, say. So lots of command line settings reqwuired in the emus, and a healthy config system in the front end to support setting all these options on a per-game basis. (And having a dsimple front end is soert od defeated in purpose if oyu have to configure the hell out of it sometimes, when its pretty easy for emu authors to just support options etting in their own app, all fresh and custom.) Other problems come into play when you need to configure how much RAM, what kind of audio, what sort of hard drives, where al these things mount to (consider DOSBox), and things like which chips to enable in the Amniga emulation, to what drives to mount as virtula hard disks on the ST, which multiple floppies to support. And then things like supporting multi-disk games in an ST or Amiga or the like ..

It gets complex fast for more complex systems.

A simple common front end itself works well for simple emus, always has (see thigns on DC, Xbox, etc.)

A simple common front-end API can work well, but its a lot fo work to set it up, and it needs to be very general. By the time its ready, the emus are already well on their way with cvustom UIs, as it is very easy to slap a custom UI together. (Consider.. porters and coders are more interested in getting their app up and going and working on efficiency and so on .. they're not spending all their time on fancy front ends, until later.)

A common set of APIs to make USB-controllers and so on would be nice too so I say work on that

jeffcrank

[mmalficia]

while im not familiar with how the command line execution works under Linux .. another thing to consider to ease your pain if you do this :

take a look at Mala and Atomic FE for the pc ive used both in my cab at one time or another.. they have a very flexible system that works well.

essentially it works like this the basic default command lines are programed in but you can over ride them via a plug in (thats really nothing more than a txt file with the name of the emulators executable then the path and then a line like this
"c:|blah\moreblah\emulater.exe %rom% %arg1% %arg2%
misc crap and options


atomic takes it a step further in that their set up is like ini files and when the emulator is called its called with %emu% %[block]% %rom% %misc%

that way if you want you can have several "command lines" for the same emu in case certain roms need special settings

and leave all the special resorce management up to each emu .. since everyones going to tweak things thier way and ultimately if you try n use your FE like a club to force every dev to commit to your system or rehack yours to play nice with every emu out thier within a year or two you wind up with a total clusterf... of misc apps special settings abandoned emus that wont work with your front end and folks complaining like its your duty to magicly make it work :> this takes all that politely out of your hands all the emus have to support is command lines with variables .. and it magicly works .. as far as the non tech end user sees ..


the above mentioned FE's both make it simple since you only drop in the files for whatever emus you plan to run and then select them from a drop down.. it makes updating a hell of alot smother to since if an emu changes you just edit the file or DL a new ini instead of having to recompile your code and get it out to everyone.

im not sure how difficult it would be to set up in your app but IMHO over the long haul its very configurable and efficient way of handling the massive amounts of possible user settings for every new emu without having to reinvent the wheel each time.

just another angle to think about

ps as far as screen caps theres all ready 2 repositorys for most of the systems i would guess the pandoras going to have .. it would just need conversions as i think thier all in hardware corect size .and saved as jpgs .. you can find all of mames screen caps at byoac and the dumping grounds. theres torrents for most of the consoles at 2 other places that if your interested send me a msg and ill get em to you. not to mention i "THINK" hyperspin still has screen caps for all goodsets names for thier supported emus on thier forums.

This post has been edited by mmalficia: 26 October 2008 - 05:32 AM

[linuxhacker]

Sounds like a very good idea (assuming emulator parameters can be passed on the commandline, although if they aren't at the moment its a hell of a lot easier to add that then drawing up some API that all emu's have to use).

If each ROM had a config file associated with it then you could set the settings (frame skip etc) for that ROM so it runs OK. You might even have a whole set of pre-baked config files on the internet which you could use if you don't want the hassle of doing it yourself, although as the same ROMs might have different names this might be a problem (what about checking the MD5 sum of a ROM as I would assume these should be the same for the same game ROM?).

The launcher could then either be a simple commandline program that gets the right commandline for that ROM or a GUI which might also get you adjust the options and save the modified commandline (think VLC stream/save window, or KCD ripper where you can either click on options or manually edit the commandline).

Just a thought (this may have already been done, I have to confess that I'm not that much of a emu person), either way K.I.S.S !

[PandoraRox]

Thanks for the replies. I think pulling down artwork from repositories would be a great idea. However, I am not a coder and I am only presenting this idea to be made by someone else. But thanks a lot, and the repiles were great.

[Aimless_E]

I like the API Idea as it would give the sometimes allusive "integrated" feel. I would be willing to code something like this(either frontend or API) as I have been working on a media center idea for a long time, but always get irritated when program X doesn't use command line options where program Y needs a new config for each game.

For everyone here how many command line options do we think would be required for a standard emu?

1.frameskip
2. under/over clock
3.keep asspect/stretch
4. sound emulation on/off
5. various fix 1
6. various fix 2
7. various fix 3
8. various fix 4
9. game rom

One would have to have a running database for every game and emu to make sure the optimum settings are used, but I believe that the POND network idea would suffice. A user could open the program, the program would check for any new db releases for all supported emus and download them as needed. Better yet it could only download the db s for the emus that are installed on the SD. The API could allow for embedding for games that don't work when stretched. How stuck on this "look" are you PandoraRox?

[dcpmark]

l offered $100 bounty for a similar single frontend for multiple emulators the GP2X without icons, but no one bit even though a few others chipped in a little more.

[PoisonedV]

l offered $100 bounty for a similar single frontend for multiple emulators the GP2X without icons, but no one bit even though a few others chipped in a little more.

ahaha, thats ridiculous. through that offer up again and the pandora and I'll do it myself- as long as the authors support arguements, the one pictured here would be pretty easy.