Homebrew organizational thoughts...

[Robbi]

first and foremost, im going to explain my situation: im about to begin my first jump into DS media cards and i am planning to order an AK2i (why i am "planning" rather than having it ordered already is because i wont be able to see my dad, AKA the guy with pay pal

, until Sunday rolls around so im gonna order it then)

i've been doing some pre-planing for what i'm going to be putting on my card once i get it and i'm really excited to get to finally play with the ds homebrew scene! but here is were i get a little... frosted...

the thing is i am organizational freak to a small extent as far as my digital files are concerned... and knowing that the interface of the AK2i uses a very simple and effective system of the classic folder list. well my plan for the organization of my cart was going to be one folder for games and have all games in there, and another for apps... the apps (and a couple of the games) are what drive me insane...

i can't stand the fact that so many of the apps that i read about and want to try out all tell me something like "in order for *abc* application to run properly on your ds cart, you must put files *xyz.pqr* and *bhd.vin* along with a folder called *useless non standard subfolder* in your default directory" and i HATE that! i had no intention of having an assortment of ugly random folders placed most likely needlessly in the default directory when they could probably be put in a subfolder to clean things up...

it's just stupid! and because of the folder list system of the AK2i i have to see them plainly and messily scattered in the default directory... i like the folder list thing because i can specify my OWN organization to my stuff... but when almost all of the homebrew apps that i am interested in (such as DSOrganize and DS Doom) require some system folder and files stupidly placed in the root directory... it just makes it fell ugly and messy for me... i really hate that...

here is what i am thinking... and it's not any sort of revolutionary idea at all... in fact it's been used in windows for as long as i can remember... HOW ABOUT SOMEONE SETS A DEVELOPMENT STANDARD APPLICATIONS FOLDER!!(with subfolders for the respective apps) is that really so hard? no it's not. not at all... so why the heck are so many homebrew apps lazily tossed into the root? if it can be done in most computer OS's why not on the DS?

if i am missing something from lack of knowledge, please fill me in because i want to know WHY they must all be messily left in the root directory? and is there a way to combat or work around this?

 

[FAST6191]

There have been attempts to standardise and indeed many support it, thread you want to read:
http://forum.gbadev.org/viewtopic.php?t=15423

You may be able to get away with hidden folders (I have not looked at the acekard line in a while so I do not know where that lies) but for the most part your OCD about folders will have to go or you will be unable to use several homebrew apps.

Workaround 2) you get a compiler (most use devkitpro and related apps or something that sits on top of it) and change it yourself. Naturally you require the source for this but from a knowledge perspective it is not that hard. The few times I have compared differences in this the changes to the binary were quite extensive so there is little chance of a simple patcher.

Oh and for the record I have countless very expensive apps wanting to put stuff all over my machine so do not go assuming more well established operating systems/machines are exempt from this one.

 

[MicShadow]

Robbi, i totally agree with you. It really ticks me off.
I just end up hiding most folders, but when i put it into the computer i get shoved a spagetti mess of folders at me.

I like it how some apps use a folder structure like /data/someapphere
If only all homebrew worked like that... or maybe some sort of built in redirection in libfat. Who knows

 

[Eponasoft]

I've suggested this to developers as well, but the end result is usually one of the following:

-no way! I like my mess.
-why don't we just use [insert name of obscure fat search algorithm]
-I already use /data

My proposal was to make one standard folder at root called gamedata, with several subfolders.

/gamedata/companyname/gamename/subfolders

For example...the game I'm on currently looks like this:

/gamedata/eponasoft/coven/folders

For folders, I have stuff like "music" "maps" "tiles" "sprites" etc.

The nice part of this system is it keeps everything organized in one folder that sits on root, and there's no chance of directory name collision as the company name keeps everyone apart.

 

[anoNL]

My proposal was to make one standard folder at root called gamedata, with several subfolders.
/gamedata/companyname/gamename/subfolders

The nice thing with standards is that there are so many to choose from

A disadvantage of your method is when a game has several executables or readme files. No-one will look in /gamedata/brosoft/awesumgaem/ for readme files and if you have 4 .nds/.gba files those clutter up the root folder much more than a single folder.

 

[DanTheManMS]

The technical answer, Robbi, is that DS homebrew files and applications have no idea where they are launched from. They don't know if they were launched from the root of the card or 50 subfolders in or loaded wirelessly via Download Play or whatever. Because of this, you can't just code the application so it loads the data files from the same folder as the *.nds file. Instead, you must hard-code the path to the data files when compiling, and many developers chose for that path to be the root of the card.

There are a couple of workarounds, but all of them require recompiling. One is the "\DATA\APP_NAME" folder naming convention, as already stated. Some apps have hardcoded support for their data files to be here, which helps de-clutter the root of your card. The apps on my card that use this are DSOrganize, Bunjalloo, AmplituDS, DSAIM, ReadMore, HTTPexec, PocketPhysics, and DSFTP.

Another option is to let the user specify where the data files are located via a configuration file (but this config file must be placed in a hard-coded location like the root folder). See SNEmulDS for an example of this, as the snemul.cfg file must be on the root of your card but by editing it you can tell it to search for SNES games in a folder/subfolder other than the default "SNES" folder.

There's also some code called Lick's Locator, which was made to let homebrew applications scan the filesystem several subfolders deep (default is 3) to find a specific filename. This is used by the Colors! application for instance, which scans the filesystem for "colors.nds" and then expects the "colors" folder to be in that same location.

So yeah, this is not a new problem, and there are a couple ways to help remedy the situation, but none of them fully fix the issue. The best bet for applications that insist on putting files on the root of your card is to email the developer and ask if they'll add support for the DATA folder, as this is the easiest fix to implement.

Eponasoft, just out of curiosity, why re-invent the wheel with the "gamedata" folder when the "data\app_name" folder naming convention already exists? Other than the fact that most developers don't use the company name here, it sounds like what you're suggesting is exactly what the data folder already serves as.

 

[Eponasoft]

A disadvantage of your method is when a game has several executables or readme files. No-one will look in /gamedata/brosoft/awesumgaem/ for readme files and if you have 4 .nds/.gba files those clutter up the root folder much more than a single folder.

Only game data is intended for the folders, not documentation. Furthermore, as a rule, documentation should either be kept apart from the game data, or tutorialized into the game itself. The .nds file can be put anywhere since you reference the absolute path. Finally, if your game has multiple binaries, it's not like you're going to use them all...just the one suited for your card. If you put all four of them at the root, that's your own mess to sort out.

DanTheManMS, because quite often, test homebrews use the \data folder for their own purposes. Furthermore, what if someone makes a game with the same name as someone else's? Using the company name and THEN the product name is a better solution, and it's also what smart PC application developers do when they install applications into the start menu (such as Adobe / Photoshop / Photoshop executable). A folder called "gamedata" is glaringly obvious as to what it does, and the usage of company name and game name makes it possible to drop-and-forget-it when it comes to putting new files onto your card. It's not about reinventing the wheel, it's about designing a better wheel. Ultimately, it's a matter of semantics.

 

[anoNL]

A disadvantage of your method is when a game has several executables or readme files. No-one will look in /gamedata/brosoft/awesumgaem/ for readme files and if you have 4 .nds/.gba files those clutter up the root folder much more than a single folder.

Only game data is intended for the folders, not documentation. Furthermore, as a rule, documentation should either be kept apart from the game data, or tutorialized into the game itself. The .nds file can be put anywhere since you reference the absolute path. Finally, if your game has multiple binaries, it's not like you're going to use them all...just the one suited for your card. If you put all four of them at the root, that's your own mess to sort out.

But then you're making a trade-off between ease of installation and keeping your flashcard clutter-free:

"Extract to root"
will always be easier than
"Extract the archive, store the docs folder somewhere on your pc, copy the game/data folder to the root of your flashcard, determine the correct executable file and copy that to the root folder as well."

But I guess it's mostly personal preference.

 

[OneMichael]

The basic file browser loaded by your card is usually never able to read text files, look at images, listen to music, or pretty much anything but launch .nds files. Because of that, it really makes the most sense to put them all in root.
My personal organization method is to rename every file to something like A23) Appname or A24) Appname so that I can sort them as I want. This way, I just scroll down the list and all similar programs are together.

CycloDS supports hidden files, so I never notice any sort of untoward system file poking out, but I have no clue if Acekard does the same.
I have folders for music, images, text, and game ROMs, and then all my apps below that.

My only real problem is that when I sort by name, Windows doesn't seem to sort the files properly, so it's hard to find what I want to when I plug my card into my computer. On the DS, everything is alphabetical.

 

[Eponasoft]

Windows XP introduced a new "smart sort" method for filenames inside Explorer. It interprets whole values rather than actual filenames.

anoNL, there's really no need for a docs folder altogether, just a single text file will suffice. Besides, you just drag n drop the binary and the folder onto your card and it's done with. It can't get any simpler than that. And if you don't know what binary your card requires then, again, that's your own mess to sort out because it's pretty obvious most of the time. People who own flash carts are generally not stupid...if they have one that requires patching of ROMs, they know it...if they have a proper slot-1 cart, they know not to use the ds.gba version. Also, "extract to root" will work just fine anyways if the archive is prepared correctly. A properly packaged archive will put everything where it needs to go, no hassles.

 

[Robbi]

yah know what... im thinking that the DATA folder is probably the best solution. and in the event that apps aren't compatible with that... i was thinking i could make a "__DOCS__" folder using the underscores to keep it at the top. then i just keep the NDS files where id like to store them im my directory structured cart.

Edit: for the record, if i were to ever get into the DS homebrew dev scene, i would most definatly support the DATA folder.