gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Appropriate data structure for file chooser?

#124780 - tepples - Sun Apr 08, 2007 4:03 pm

I'm writing a file chooser for a DS app. Is it safe to assume a limit of, say, 256 valid files and folders inside a folder and malloc() enough to hold their names and stats, or should I dynamically resize the array with realloc() as I get results back from dirnext(), or should I use a linked list? What does your file chooser do?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#124790 - Zarxrax - Sun Apr 08, 2007 6:09 pm

I limit mine to 256, and if it gets more than that just don't try to store them.

Whether it's safe to assume a limit like that really depends on what kinds of files people will be listing. For instance, if you are listing NDS roms, I think it would be fairly safe to say that no one would ever have more than 256 in a single folder on their card. If it's something like images or text files though, I can see certain instances where a person MIGHT have more files than that. As long as the user is aware of the limit, I don't think there should be a problem.

#124792 - Touchstone - Sun Apr 08, 2007 6:47 pm

tepples wrote:
I'm writing a file chooser for a DS app. Is it safe to assume a limit of, say, 256 valid files and folders inside a folder and malloc() enough to hold their names and stats, or should I dynamically resize the array with realloc() as I get results back from dirnext(), or should I use a linked list? What does your file chooser do?

I would assume you only need to hold the information for as many files as you can display at any given time. When the user scroll down in the list you simply do the dirnext() to get information for the next file.

I guess it depends on what you want to achieve though. If you want to have the fastest and best looking file chooser you probably want to pre cache information about every file in the directory, and if you want the most memory efficient and compatible file chooser you'd probably have to read information about the files currently visible to the user. Or maybe you want something in between.

As a professional programer I'd say you can't assume a limit of X files, but as a hobbyist programmer I'd say screw that, if someone have more than X files in one directory, just inform them of the limitation and only display the X first files, complete the app and later on improve on any annoying limitations.
_________________
You can't beat our meat

#124793 - DragonMinded - Sun Apr 08, 2007 6:53 pm

In DSO, I simply realloc for every new item in a directory. The speed isn't affected by this as much as it is by just listing the entire directory. I have, however, created a struct that gets reallocated, not just a char *buffer or something, as I precache the icon, name, etc.
_________________
Enter the mind of the dragon.

http://dragonminded.blogspot.com

Seriously guys, how hard is it to simply TRY something yourself?

#124797 - DekuTree64 - Sun Apr 08, 2007 7:28 pm

I loop through and count all the files, then allocate space, then loop through again storing the info for them.

If speed was a problem, I'd probably start with enough space for maybe 64, and realloc to 2x as much each time it fills up.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#124807 - tepples - Sun Apr 08, 2007 8:32 pm

Touchstone wrote:
I would assume you only need to hold the information for as many files as you can display at any given time. When the user scroll down in the list you simply do the dirnext() to get information for the next file.

Because there is no dirprevious(), what should be done when the user scrolls back up under your scheme?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#124808 - sajiimori - Sun Apr 08, 2007 8:41 pm

Start from the beginning again and count up to n-1. ;)

#124810 - Lick - Sun Apr 08, 2007 9:08 pm

You could pre-cache every subdirectory of only the current directory (depth = 1). That saves memory.
_________________
http://licklick.wordpress.com

#124811 - Touchstone - Sun Apr 08, 2007 9:12 pm

tepples wrote:
Touchstone wrote:
I would assume you only need to hold the information for as many files as you can display at any given time. When the user scroll down in the list you simply do the dirnext() to get information for the next file.

Because there is no dirprevious(), what should be done when the user scrolls back up under your scheme?

I don't know the interface you're using so I can't tell you the most efficient way to solve it, but what sajimori said springs to mind. :-)
_________________
You can't beat our meat

#124817 - sajiimori - Sun Apr 08, 2007 10:26 pm

As an added bonus, you can scroll from the bottom of the list to the top in only O(n^2) time! :P

#124818 - HyperHacker - Sun Apr 08, 2007 10:38 pm

Mine is not very efficient but works well enough for the application in question. It only needs the names of the files, so it simply allocates an array of 256 * (Number of files) characters, reallocating it for each item read in with dirnext() (actually the GBA_NDS_FAT equivilant because it's old code I haven't switched to libFAT yet, but anyway). Once the listing is complete it allocates a second array the size of the first and copies the filenames into it in alphabetical order (making exceptions so that '/' is the first character, so directories are listed before files), then frees the first.

Does dirnext() return files in alphabetical order? That'd make things easier.
_________________
I'm a PSP hacker now, but I still <3 DS.

#124822 - Lick - Sun Apr 08, 2007 11:13 pm

HyperHacker, you don't need a second array if you use a good Sorting Algorithm.
_________________
http://licklick.wordpress.com

#124828 - DragonMinded - Sun Apr 08, 2007 11:40 pm

Lick wrote:
HyperHacker, you don't need a second array if you use a good Sorting Algorithm.


What he said. Why not use the qsort function? I use it for all my sort code and I need no additional memory.
_________________
Enter the mind of the dragon.

http://dragonminded.blogspot.com

Seriously guys, how hard is it to simply TRY something yourself?

#124899 - HyperHacker - Mon Apr 09, 2007 8:40 pm

Yeah, that's something I've been meaning to work on, I was just lazy.
_________________
I'm a PSP hacker now, but I still <3 DS.

#124915 - Darkflame - Mon Apr 09, 2007 10:31 pm

Quote:
I'm writing a file chooser for a DS app. Is it safe to assume a limit of, say, 256 valid files and folders inside a folder


Not on my card you can :p

My NES games A-E folder has about 400 games in it :p

(and my Comic Book folder is nearly approaching 200)
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.

#124916 - josath - Mon Apr 09, 2007 11:01 pm

Darkflame wrote:
Quote:
I'm writing a file chooser for a DS app. Is it safe to assume a limit of, say, 256 valid files and folders inside a folder

My NES games A-E folder has about 400 games in it :p

(and my Comic Book folder is nearly approaching 200)


That's quite a collection, I only have like 15 NES carts. Do you have them in a display case or anything? That would look cool I bet.

#124987 - Darkflame - Tue Apr 10, 2007 6:24 pm

Ok, maybe they arnt all legal.
But, that said, I do have quite a big Nes collection.

Not as good as my C16/Plus4 collection, mind you.
Chairty shops are a gold mine for cheap old games.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.

#125036 - HyperHacker - Wed Apr 11, 2007 12:16 am

Well I'm sure that includes a lot of homebrews which aren't available on carts, right?

Also my MP3 directory has 273 files in it.
_________________
I'm a PSP hacker now, but I still <3 DS.

#125054 - Darkflame - Wed Apr 11, 2007 1:15 am

My DS Homebrew or my commadore plus/4 homebrew? :p

Got easily over a hundred DS Homebrew things, but they are a bit better organised in sub folders.
eg,
~Games,
~~WiFi Games
~Apps
~~WiFi Apps
~Emulation
ect.

Other stuff on my DS Card is far less organised.
Computer game sound tracks, Midis and the like are just one big mess of files.

oh, and sadly, my Commadore Plus/4 homebrew is still on tapes :p
One of these days I might print out and OCR some of my stuff to run them on emulators just for fun.
Didnt make much interesting anyway. A conways game of life here, a 0's and X's game there.
Best thing I did on my Commadore is a program to make it print out graphics on a text-based printer. Utterly useless to port.
_________________
Darkflames Reviews --
Make your own at;
Rateoholic:Reviews for anything, by anyone.

#125079 - chishm - Wed Apr 11, 2007 5:30 am

I'd suggest using a double-linked list, add items as you read them, then sort the list when you're finished. C++ has the STL, which can make creating and sorting the list pretty easy to do.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com