Re: [AD] search path?

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


I'm just trying to understand the API a bit more and I've forgotten
all the previous discussion. Is there any more documentation apart
from the stuff at http://alleg.sourceforge.net/a5docs/ ?
Is it possible to 'reset' al_readdir and enumerate through it again?
And, is there a way to set the CWD to an ALLEGRO_FS_ENTRY? That would
seem to me to be quite useful, say if you put all the resources in a
zip file.

Pete

On Tue, Apr 14, 2009 at 3:11 PM, Elias Pschernig
<elias.pschernig@xxxxxxxxxx> wrote:
> 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>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> --
> https://lists.sourceforge.net/lists/listinfo/alleg-developers
>




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