Standardising Emus

[second exodous]

I think Tetedeiench has a point, but I'm not sure why he frequents these forums if he sold his GP2X... Oh well. Anyway, he sums it up here:

Getting something to work on the g2x is just HELL. While I'm skilled on Linux, i HATE how programmers come up with different standards that just kill any organisation you can have on your SD card. Want to put your games in the games folder ? . . . DrMD frces you to make a Roms/MD directory.

​

He's correct, every emu is different. As for DrMD forcing you to make a /rom directory, I think it's brilliant, and every emu should do this. The emulator's .gpe should be in the root dir for fast access and the roms should be in /rom/megadrive, /rom/snes, /rom/nes, /rom/pcengine, .etc to keep them out of the way of the /root dir.

Also, I think Emulators should standardize on the method of save states and such. I was thinking a key-stroke that would never be used in an Emu would be nice, but that's kind of hard to come up with. I noticed in the Test Mode you can press both volume up and volume down at the same time by pressing in the middle of the volume control. How about:

Volume up + Volume down + Left shoulder button = load save state
Volume up + Volume down + Right shoulder button = Write save state

Then in either of the save or load emu's you could hit Y to go to a menu to exit the emu and other things. This would also speed up saving and loading drastically.

Anyway, this is just and idea. I understand that when an emu is in beta before rom selection is implemented the rom is usually in the same folder as the launcher, I'm just saying for finished emus. And I'm not sure what would use the volume key-stroke above, someone might come up with a better solution. Right shoulder button + Left shoulder button won't work on a SNES emu though, but works fine in DrMD, but it would be nice to have a standard.

Thanx,
Stan

 

[Deed]

I think that people that are ranting and grumbling about free software, and that do not want to spend some time to configure these softwares, understand how it works, etc ... should simply buy a psp, a gba or a ds, and buy their games at the store behind the street.
Remember you should only be grateful, kids. All of this is free, and clearly unexpected. Never think about the guys that actually take the time to dump roms ? Without speaking of the ones that actually code emulators ...

 

[RiX0R]

I think that people that are ranting and grumbling about free software, and that do not want to spend some time to configure these softwares, understand how it works, etc ... should simply buy a psp, a gba or a ds, and buy their games at the store behind the street.
Remember you should only be grateful, kids. All of this is free, and clearly unexpected. Never think about the guys that actually take the time to dump roms ? Without speaking of the ones that actually code emulators ...

​

So you are basically saying: if you don't have to pay for it, expect it to be shit?

I don't agree with that at all.

 

[Empyre]

I disagree, no path should ever be absolute, they should always be relative and any locations for files that are not a pert of the app (ie roms) should be user settable via either a menu option or an ini file type system.

What if i want an /mnt/sd/emu folder? I cant put drmd in it (well I can but it still insists of putting its settings in a /mnt/sd/drmd folder not /mnt/sd/emu/drmd

Edit:

So you are basically saying: if you don't have to pay for it, expect it to be shit?

I don't agree with that at all.

I think what he's saying is if its free we have no right to _demand_ anything, and hes right.

I think it's ok to ask though, just don't get upset if the author says no.

 

[second exodous]

Well, I'm just saying as a Linux user I see great things come out of the KDE project because of standardization. I think games on the GP2X could be the same. It's possible to have a standard on any software, be it commercial or community, it just takes a little effort on everyone's part.

I disagree, no path should ever be absolute, they should always be relative and any locations for files that are not a pert of the app (ie roms) should be user settable via either a menu option or an ini file type system.

What if i want an /mnt/sd/emu folder? I cant put drmd in it (well I can but it still insists of putting its settings in a /mnt/sd/drmd folder not /mnt/sd/emu/drmd

​

Hmm, I see your point. I think having the .gpe file in /root, or as your would put it /mnt/sd, is better just for fast access. Or a script could be written so when you select games it goes directly to the /Emu or /Games folder.

As for roms though, I think it's best to have them all in the same place just for organization.

Thanx,
Stan

 

[DelTa_ViRuS]

I certainly don't think trying to create a standard should be frowned upon. Like I don't believe the directories should be absolute. Maybe just relative; some standard. Or an easy way to configure.

I have absolutely no problems configuring these emu's to go. But having a standard at least may help. It never ceases to amaze me the amount of blantent bitching on this forum. Hear out people's ideas. You guys certainly don't encourage new comers to adopt the GP2x; I came to the GP for the community.. but came out unimpressed.

Breathe people...

 

[Deed]

So you are basically saying: if you don't have to pay for it, expect it to be shit?

I don't agree with that at all.

​

That's absolutely not what I was meaning. Basically : if you don't have to pay for it, don't expect anything.

It never ceases to amaze me the amount of blantent bitching on this forum. Hear out people's ideas. You guys certainly don't encourage new comers to adopt the GP2x; I came to the GP for the community.. but came out unimpressed.

​

That's because we're thinking we're so smart because we're able to manage all of these non standardized paths We are the 3l1t3 here !

 

[Paradox]

i would hate to have my roms in a set directory, currently, I like to have my roms in Games/Platform/Genre, forcing me to put them into roms/platform is silly, having any standard is stupid, as long as you are able to set your own directory, everything would be fine

 

[DelTa_ViRuS]

Hacking on the emu's and homebrew doesn't bother me, but newcomers have a tough time getting in.

So play nice

 

[TelcoLou]

I don't mind so much, as long as the Readme is super clear as to where everthing belongs.

I actually had to talk another co-worker out of buying one, since he's basically PC illiterate and asked me if I could 'set everything up' for him.

 

[K-teto]

Would you let us work as we want to?
Thanks.

 

[Empyre]

Hmm, I see your point. I think having the .gpe file in /root, or as your would put it /mnt/sd, is better just for fast access. Or a script could be written so when you select games it goes directly to the /Emu or /Games folder.

As for roms though, I think it's best to have them all in the same place just for organization.

Thanx,
Stan

Exactly... YOU think all gpe's should be in /mnt/sd. I don't.

If every app had no associated files then yes, that would be great but what about neogeocd? it has a skins folder as well, so does the nknes and nksnes emus, they would all conflict if they were all in /mnt/sd. If they all had a different name (nknes_skin, nksnes_skin etc) then i would have 3 folders to scroll past to get to the gpe after a while you end up having to scroll past lots of dirs to get anywhere.

I personally think all apps should be in /mnt/sd/bin/<appname> folders and a script called <appname>.gpe should be in a /mnt/sd/emu folder.

Its all personal preference, relative paths mean you can set up your sd however you wish.

 

[second exodous]

Upon seeing so many people wanting to set their own directory, I have a standard that will work for everyone. How about a standard con fig file? The file would look something like this:

Bob's emulaor for superimagineworldsystem:

#stuff that the Bob wants to say here

#set your rom directory here, uncomment or set your own:
/roms/siws
#/games/siws/roms

Having a set rom directory is nice, but how does everyone feel about my idea to have a standard save state/load state method?

Thanx,
Stan

 

[Empyre]

Would you let us work as we want to?
Thanks.

​

You are free to work however you like, you are the one producing the stuff we just play with.

Feel free to ignore all of this thread, its just a bunch of non-devs moaning because they want something different.

You can't please all the people all the time so just please yourself, we will live with it.

 

[second exodous]

If every app had no associated files then yes, that would be great but what about neogeocd? it has a skins folder as well, so does the nknes and nksnes emus, they would all conflict if they were all in /mnt/sd. If they all had a different name (nknes_skin, nksnes_skin etc) then i would have 3 folders to scroll past to get to the gpe after a while you end up having to scroll past lots of dirs to get anywhere.

I personally think all apps should be in /mnt/sd/bin/<appname> folders and a script called <appname>.gpe should be in a /mnt/sd/emu folder.

Its all personal preference, relative paths mean you can set up your sd however you wish.

​

Oops, you beat me to the post, the config file I mentioned above could set where the .gpe file looks for everything, not just roms. I guess a config file could set key strokes also....

Oh, and Empyre, I'm not attacking you, I saw your point, but there just has to be a better way to standardize things and keep everyone happy. I think a config file is the way to do it.

But I'm just suggesting ways to do this, does anyone else have any idea's?

Thanx,
Stan

 

[Paradox]

im not too pissed about a standard save/load state, but i have suggested the idea in the past about having a file/script that comes with said emulator for which you can change/specify the working rom directory, now getting all the devs to adopt this idea would be the hard part, for now thugh, just let em work on actually making the emulators better

 

[rokdcasbah]

the problem with standards is that everyone has to agree on them

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. and the frontend could stay in memory, activated by a certain key combo. or is that too much like scripting?

even with something like that, there still needs to be a sort of consensus, and obviously it's easier to come up with fixes than to implement them.

and a little hacking around never hurt anyone...

 

[Deed]

Having a set rom directory is nice, but how does everyone feel about my idea to have a standard save state/load state method?

​

Seriously speaking, I think this kind of standard can only emerge "de facto". Otherwise, all emu coders should organize meetings, decide what is the best ... You don't imagine how difficult it is to standardize something from scratch ! But, if the two most popular emu use the same way to save states, maybe be they will be followed by a third emu, then a fourth, and so on ... simply because even emu authors are used to save states using this method ! Et voila ! A de facto standard !

 

[second exodous]

Yeah, I understand that in development, which pretty much every piece of software on the GP2X is, things aren't standard. I'm just suggesting a way to get there, I'm not surprised that the config file idea has been mentioned before Paradox, a lot of programs in the open-source world use that, as commercial apps.

Yeah, it's too early to expect this stuff, but maybe we should start thinking about it now. I'm in no way an organizer, look how mad I make people, but it would be nice. Maybe I should post this on a GP2X dev forum/site since this would be more relevant to devs than users at first.

Thanx,
Stan

 

[wyefye]

We need to figure out(figure out, psh) how to make symbolic links to gpe's. solves the dependencies and makes organization better. - so long as we can destinguish that it is actually a link... eh..