Standardising Emus

[DijiTao]

http://wiki.gp2x.org/wiki/Common_User_Inte...Recommendations

 

[skeezix]

Roms are easy; most should look in /roms/system as a relatively common and easy standard; MAME doesn't do it, but many/most do nowadays. However, it shoudl be like this, which is what I'm aiming to do with mine..

Look in..
1) /roms/system
2) ./roms
3) read ./rompath.txt and the single line there says where to look
4) read app specific config file, looking for app-specific configs

So in outcast's sake..

1) /roms/atari-st <-- does now
2) ./roms <-- from current directory
3) ./rompath.txt
4) /roms/atari-st/default.cnf
5) ./default.cnf

That should cover _everyone_

(ie: akin to the .dot-rc files in unix/linux)

jeff

 

[Paradox]

yep that would cover anyone i guess

 

[Drak]

What is there to make easier?

All the stuff is common sense if you read the readmes. The only thing that may be confusing to those is getting bios files and such. :rolleyes:

 

[Aninhumer]

I would have thought that seeing as most of the Gp2x projects are open source it wouldn't be hard to modify them to use relative paths. I thought that was what open source was for.
I guess as only a newb-dev these comments carry a lot less weight, but I always hate it when devs complain about small features of open source programs.
My idea for a standard was to have one data folder on the SD with all the actual stuff in, and then everything else is links or folders with links. Forcing a standard layout on people is pointless, but with relative paths we can at least arrange what we have how we want it.

 

[Empyre]

I would have thought that seeing as most of the Gp2x projects are open source it wouldn't be hard to modify them to use relative paths. I thought that was what open source was for.

This is true but unless that change makes it back to the main source tree you would have to remake the change for every new release of the app.

 

[RiX0R]

i realize that's pessimistic. but what about a front end for multiple emu's? maybe such things exist but i can't really investigate till i get my own unit. but, say, if all your emus could have options passed externally at runtime (probably already possible) and you could set up your front end to handle all that stuff.

​

^--- I'm with stupid on this one.

If all emulators would accept the ROM to load as a command-line argument, we could use a menu, launcher or frontend that would work with the ROMS placed anywhere the user wants 'em to.

In fact, that's kind of what I'm aiming for with my menu Mocca.

 

[Squidge]

and SquidgeSNES already has command line options to do this You can tell it (via the command line) to exit rather than load /usr/gp2x/gp2xmenu (eg. you want to exit back to your own menu system), and you can pass a rom to load, in which case it will by-pass it's own menu.

 

[Aninhumer]

I would have thought that seeing as most of the Gp2x projects are open source it wouldn't be hard to modify them to use relative paths. I thought that was what open source was for.

This is true but unless that change makes it back to the main source tree you would have to remake the change for every new release of the app.

I guess, but it would still be an improvement, besides if the developer realised that more people had downloaded the relative version, they would probably add it to the main source tree.