[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Major API change for SDL 0.9.11
Sam Lantinga wrote:
> I'm implementing "load-from-memory" for SDL_LoadWAV() and SDL_LoadBMP().
> The most flexible way to do this is to implement a general data source
> abstraction and allow you to define your own data sources. This should
> help people writing PAK file compilers and so forth.
> Comments anybody?
> SDL_LoadBMP(SDL_RWFromFile("sample.bmp", "rb"), 1, ...);
> The SDL_LoadBMP() function will close the opened file automatically.
How does SDL_RWFromFile () work? In particular - how do you determine
get the file? If I want e.g. open something contained in a PPlay
do I tell SDL_RWFromFile() and how does it contact the PPlay Fiel
(PPlay PakFiles have to be "mounted" with ppfMountPak
before use; Files are then opened via
ppFILE myfile = ppfOpen ("pakfile://somedir/mypak/myfilename", "rb") or
ppFILE myfile = ppfOpen ("file://somedir/mypak/myfilename", "rb") or
ppFILE myfile = ppfOpen ("somedir/mypak/myfilename", "rb")
and accessed with ppfRead (myfile, ...) etc
(the last two ppfOpen () calls are synonyms, looking for the file both
the mounted pakfiles and the normal filesystem, the first one looks only
I currently see two solutions to this:
(1) you also use some URL scheme
(2) you define some "data source" objects (well, interfaces) and let the
pass instances of those to SDL_RWFromXXX ()
Iīd favor the first one, as there should be little that cannot be
an URL. URLs are slightly slower, but thatīs only relevant for those
"letīs use thousands of tiny files" games (and for those some speedup
like PFileīs open-by-number can be used (which is btw also beneficiary
if you just use normal filenames)).
And the URL thingy is certainly nicer to handle for the user.