[Borgland]

Added a task with a patch to change the browserList to std::vector. Any feedback would be appreciated.

When merging I saw an mplayer file (subs/subreader.b including filebrowser.h) including a WiiMC file. This dependency seemed strange to me. Shouldn’t it be the other way around? Either way, I fixed it by adding a new define.

[Borgland]

See wiimc.cpp:
browserList = (BROWSERENTRY *)mem2_malloc(sizeof(BROWSERENTRY)*MAX_BROWSER_SIZE, VIDEO_AREA);
Doesn’t matter if it has less than 2000, at the moment this is the memory allocated in the MEM2 area called VIDEO_AREA.

Ok, I missed that one, you are right.

You can just as easily use structs, malloc, etc. I’m not completely opposed to C++, but also realize that it is going to use more memory up to use classes – C++ increases the footprint.

I want to use a class to encapsulate the browser list idea. One advantage is that it hides the details of the relationship between the browser struct and browserList list. If a programmer has to call AddBrowserEntry() every time he/she wants to add a new entry to the browser AND remember to call browser.numEntries++; eventually someone will forget, and cause a bug.

How about, we start addressing the larger memory issues first. Can I change browserList to be of type std::vector so that the initialization of all 2000 entries isn’t done upfront?

[Borgland]

After reading through some of the code I want to make a suggestion. The browserList and browser global variables are used in quite a few places in more or less the same way. I want to encapsulate this in a class. The interface that I thought of so far could be something like this:

class Browser

{

public:

static BROWSERENTRY&  getBrowserEntryAtIndex(int index);

static BROWSERENTRY&  getSelectedBrowserEntry();

static void addBrowserEntry(const BROWSERENTRY& entry);

static std::string getLastDirectory();

static std::string getCurrentDirectory();

static void setSelectedIndex(int index);

static int getNumberOfEntries();

/* TODO more things here */

};

This of course does not include all the members of the BROWSERINFO browser struct yet. My idea is that this class will completely take over the way the browserList and browser structs are currently used.

Eventually this class could also contain a list of directory entry lists, so that we can hold more than one level of directory entries at a time. (I thought that WiiMC could only re-parse a folder once it enters it, instead of on every directory change.)

I want to hear what you guys have to say about this suggestion before I submit a patch.

Tantric: you said that “WiiMC sets aside 2000 directory entries for one directory path”. That’s true, but only for directories with 2000 entries. Directories with less entries will luckily use less memory. (See AddBrowserEntry() in filebrowser.cpp )

jhb50: I haven’t taken a good look at the picture mode code, but I guess to solve your problem, would be to filter the directories earlier, for different modes. Does WiiMC know what extensions it supports for a given mode?

[Borgland]

Ok, found this thread. Seems like the compile instructions are a little out of date.
Thanks for the solution clava.

[Author]

Posts