[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 2009-04-14, Elias Pschernig <elias.pschernig@xxxxxxxxxx> wrote:
> Peter Hull wrote:
> > 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/ ?
>
> No, it should have the complete fshooks API as it is in current SVN. Which is
> rather incomplete right now of course.
>
> > Is it possible to 'reset' al_readdir and enumerate through it again?
>
> In PhysFS, the default read/write dirs are empty. So if we copy the semantics,
> an attempt to read a file without calling al_add_search_path will always fail.
> Same for writing.
>
> > 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.
>
> This part is still missing. fshook.c has this:
>
> struct ALLEGRO_FS_HOOK_SYS_INTERFACE *_al_sys_fshooks = &_al_stdio_sys_fshooks;
>
> So all functions right now always use stdio. We have yet to decide how things
> like a zip/physfs addon should work. Should we really use the above global
> variable? Should it be a global, but per-thread? Or is there a better way
> alltogether to add this to the API?
That was my next question. I think we need to be able to register
handlers for different URI schemes. At path without a URI scheme will
default to file://, which is implemented with stdio, but may be
overridden if you want to remote filesystem support (somehow).
I think we can delegate the search path stuff to the backend that
implements each URI scheme. e.g. you can have "phys:baboon.tga"
search through multiple archives, you just have to use backend-specific
functions to set the search path.
Peter