Total Disorganization


gaijinflyer

Still Fresh
Joined
Dec 10, 2005
Messages
10
Love the emus and ports (DrMDX, nkNEOCD, uqm, MAME...). However, I have a complaint. Freedom , apparently has its price.

My SD card looks like a folder explosion. Not the organized /games /movies /music /photos /utils that I thought I would wind up with. There are all kinds of folders at the root level (mandated in the readme.txt files). Why is this so? Why does cpu_speed.gpe show up as a game? Isn't it a util?

I thought Linux would be easy to use relative paths for apps. Shouldn't that make it easier and not harder for the developer.

Is this just a phase as devs push out 0.?? versions of emus and ports? Will this forever be the cost for of the lack of rigid standards that a locked down hand-held would require?

Again, not bitching real strongly, it's just not as organized as I thought it would be.

Regards in the new year.
 
You can write your own scripts, and point the executables to whatever folder/directory you want ... (though I haven't the free time to learn how myself)
 
My SD card looks like a folder explosion. Not the organized /games /movies /music /photos /utils that I thought I would wind up with.
I feel your pain. I also (naively :)) setup a nice directory structure, only to find that I had to place things all over the place. Some bother me, some don't (i.e. /roms seems OK).

It's surely a mess now, and hopefully more devs will use relative instead of absolute pathing. But hats off to the devs regardless, the GP2X has been a complete blast so far because of their efforts.

Note: I've been guilty of coding absolute paths myself on more than one or ten occasions ;)
 
Last edited by a moderator:
hehe me too, i had this whole nice directory structure laid out only to find each app wants its own special directory in the root and stuff.
 
It's purely lazy programming on the part of the writers of the apps. Any application should be able to work using relative paths.

For the original poster, if you want cpu_speed.gpe to be a util, change the extension to .gpu.
 
It's purely lazy programming on the part of the writers of the apps. Any application should be able to work using relative paths.

exactly! I've been guilty of this myself many times :)

though, in this case 'lazy' is a relative term. these dev's are working for the love of it, and producing some fantastic ports, and homebrew creations, in their free time, just because they want to. so we gotta cut them a little slack.
 
Last edited by a moderator:
though, in this case 'lazy' is a relative term. these dev's are working for the love of it, and producing some fantastic ports, and homebrew creations, in their free time, just because they want to. so we gotta cut them a little slack.
True. Their efforts are applaudable, and much appreciated by the community. Now we just need to raise the bar that little bit more and have the apps behave nicely with regard to install directories.
 
Last edited by a moderator:
being of the developer ilk i know how its easier to conform to a common standard if one exists, why dont we propose one as a group and put in the Wiki and then any developer will know where to store things. (saves them even thinking about it !).

For instance the roms\megadrive emulator makes great sense, how about a standard of <root>\roms[machinename], moving on i am sure there are loads of others.
 
Last edited by a moderator:
being one of the developers i know how easy it is to use the common standard known as "relative paths".

i don't understand why all the other developers insisted on using /mnt/sd/roms where they could've just used roms/ and we would have no stupid directory trouble.

nk did it, why can't the others do it?
 
If you're going to push for a stardard, surely it should be that games ought to be self-contained units - any files the game needs should be stored in or under its own directory. Beyond that, it's up to the user where they put the files, and the games should work regardless.

This is kind of contrasting the Windows vs Unix ways of installing files - in Windows, an app's files go in its own directory, while in Unix an app's files are scattered over the filesystem, as the directories they go into are determined by the file's content (executable code in 'bin', non-executable code in 'lib', portable data in 'share', manpages in 'man', other documentation in 'doc'...) For a solo homebrew developer it's a lot easier to encourage the ability to install and uninstall the app with little hassle, by putting everything in one directory (tree) and allowing users to just delete the whole lot when they don't want it any more.

Actually I do most development in Allegro, which comes with routines to bundle all your data into a single datafile, and even tag that on the end of your executable so you really do only need to distribute a single file.
 
Not true. A lot of windows programs will install it's own DLL's or INF's into the windows/system32 directory and implant several registry keys. The windows registry is a jungle of paths in itself. However, I agree with the masses here and believe that it shouldn't be to hard to change the way the paths are setup. Maybe just adding small shell scripts to point to roots and creating an interface that still shows you basic folders to give the illusion that it's cleanly organized.
 
being one of the developers i know how easy it is to use the common standard known as "relative paths".

i don't understand why all the other developers insisted on using /mnt/sd/roms where they could've just used roms/ and we would have no stupid directory trouble.

nk did it, why can't the others do it?

I second that.
 
Last edited by a moderator:
there is a thread that i started asking bout shortcuts, if you have a unix text editor its easy.

I have links to all the .gpe's in a single folder called games, there is still alot of folder though, i was hoping there could be a way to automatically open the game folder when game is selected from the linux menu.
 
how about instead of a set directory, some sort of setting.ini file, where we get to choose where we want our things to go, for me, my games are sorted like this:

root/Games/Sega Mega Drive
..................Super Nintendo
..................Nintendo Entertainment System
..................Neo Geo CD
..................Gameboy
..................Etc...

then

!Console/ Action
...............Shmup
...............Platformer
...............Puzzle
...............Racing
...............Beat Em' Up
...............Etc...

then DrMD came out and i had to shift all my roms out of the relative genre directories i had sorted them nicely into and plonk em all into /roms/megadrive.

im living with it, its not too bad, but im sure sometime in the future there will be a way to change it with all roms/applications
 
I agree with some of the points that have been raised, however, I disagree on the idea of a common standard, at least in the way I interpreted it.

Everyone is different, and have different preference for organising. I would simply like the ability for it to be up to me where I put things, rather than being forced into a certain setup one way or another. For example, some people may prefer /sd/roms, wheras some may prefer a roms subdirectory in the emulators own directory.

I think the best option would be to give this freedom. Perhaps a config file if necessary, where if required, the paths, where used, could be changed to the users specification.
 
If all of the programs are open source, I'm suprised no annoyed dev hasn't already rewritten some of the programs to include relative paths.

I realise that it is the job of the developer to write it right the first time, but you can't really complain about them being lazy if you yourself are too lazy to rewrite them.

By the way, what about symbolic links? They could present an answer to these problems, especially if they don't appear to the user normally, that would mean you could have the illusion of an organised filesystem.
 
The folderconfig.ini file is a crackin idea.
U'd just need the one file in the root of the SDcard & u'd be able to modify it easy enough for your individual needs.
How come this wasn't used in the first place? I can't see any down sides to it :unsure:
 
By the way, what about symbolic links? They could present an answer to these problems, especially if they don't appear to the user normally, that would mean you could have the illusion of an organised filesystem.

The SD card is FAT32 formatted. FAT32 doesn't support symbolic links.
 
I had also organised my SD card before I got my unit. It was something like this:

Apps/
----->PDFView/
--------------->PDFView.gpu
Games/
----->DrMDx/
--------------->roms/
----->SNES2x
--------------->roms
----->Quake/
Movies/
-------->Doom.avi
-------->Kill_Billv2.avi
Music/
----->Bjork/
------------->Debut/
--------------------->*.mp3
------------->Vespertine/
--------------------->*.mp3
------------->Greatest_Hits/
--------------------->*.mp3
Utils/
----->CPU_Tweak.gpu


This made me happy because I could easily find alot of stuff quickly. After getting the unit and installing DrMDx and Quake I found that I had to abandon my structure altogether. I know quake should have worked with a script... but it didn't... must have wrote it wrong ;) anyways....

The 3 options I see to fix this problem are as follows:
- Self Contain all program files in each programs own directory (relative paths)
- Write a script/menu/gui that scans the entire SD card and puts everything under the correct sub-menu (this would be alot of work)
- A universal .config file in the base of the SD card that would let the interface know the directory structure and what progs open what files etc. (Also alot of work)

I am also not against a standard structure either. Something like:

/apps
------->PDFView.gpe
/games
------->quake/
----------------->ID1/
----------------->quake.gpe
------->DrMDx/
----------------->DrMDx.gpe (all emulators point to /mnt/sd/roms/EMULATOR)
/movies
--------->movi1.avi
/roms
------->megadrive/
-------------------->sonic1.md
------->snes/
--------------->mario.snes
------->psx/
------------->one.bin
------------->crash.bin
/utils
------>CPU_Tweak.gpu

As long as EVERYONE stuck with the structure this would be fine by me. I just want some level of organisation. Also I think devs should ALWAYS static link their binaries, there is nothing worse than having to install extra libs!

my 2.45 cents ;)
 
Back
Top