Re: [AD] search path?

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Thomas Fjellstrom wrote:
On Tue April 14 2009, Peter Wang wrote:
What was the motivation for the search path stuff, i.e.
al_add_search_path, etc.?

I don't see any reason to keep it.  It's likely a source of confusion as
most people passing a relative filename will expect it to be opened
relative to the current directory only, not relative to some set of
directories.  And when you consider opening files for writing...

Its been asked for many times. I personally think its useful, and physfs uses
it to find paths and to tell it to use archives as paths as well. With a physfs addon, you'd access files in archives like so:

al_add_search_path("archive.zip"); // contains music and images folders
ALLEGRO_FS_ENTRY *game_opening = al_fopen("music/game_opening.ogg");
// or alternatively
al_load_sound("music/game_opening.ogg"); // if the acodec ogg code uses allegro's fshooks properly, it'll find it in the zip file

And it is quite convenient to use without archives.


I just looked at physfs, they also allow setting a (single) write path which is used instead of this when writing. So if we want it, we also need a way to set the write path. And we also need to do something akin to their permitSymbolicLinks function.

http://icculus.org/physfs/docs/html/physfs_8h.html

However, I think this is too confusing, with little benefit. The code intense part here is constructing the directories using al_get_standard_path(). So, all this function does is, instead of calling al_fopen for each of your paths, you now pass each path to al_add_search_path first, then call al_fopen. It seems mostly pointless - a simple wrapper function has just the same effect.

--
Elias Pschernig <elias@xxxxxxxxxx>




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/