Hi all,
I wonder if there is a reason for SDL_LoadWAV, SDL_LoadBMP and SDL_SaveBMP
to take a file name as an argument.
Taking a FILE* instead would make them more flexible, for example allowing
the user to use some kind of WAD-file format or loading resources from an
already open socket connection and so on …
See you
I absolutely agreee.
I wonder if there is a reason for SDL_LoadWAV, SDL_LoadBMP and SDL_SaveBMP
to take a file name as an argument.
Taking a FILE* instead would make them more flexible, for example allowing
the user to use some kind of WAD-file format or loading resources from an
already open socket connection and so on …
Consider it a feature request.
SDL 0.9.5 will have SDL_FPLoadWAV, SDL_FPLoadBMP, SDL_FPSaveBMP, etc.
Hello,
Consider it a feature request.
SDL 0.9.5 will have SDL_FPLoadWAV, SDL_FPLoadBMP, SDL_FPSaveBMP, etc.
thanks for your quick response. Actually, I am not sure if FILE* is the
perfect way.
What if someone is using a compression or encryption algorithm in his
WAD-file? Or if someone (like me presently) is trying to use SDL behind a
C++ driver interface that gives a stream to read the resources from?
The only solution I can see is providing a callback function, like:
typedef size_t (*SDL_ReadFunc)(void *ptr, size_t size, size_t nmemb,
void *data);
SDL_AudioSpec SDL_LoadWAV(SDL_ReadFunc func, void func_data,
SDL_AudioSpec *spec,
Uint8 **audio_buf,Uint32 *audio_len);
/* Example for a callback function reading from a file: */
size_t FileRead(void ptr, size_t size, size_t nmemb, void data)
{
FILE file = (FILE) data;
return fread(ptr, size, nmemb, file);
}
What if someone is using a compression or encryption algorithm in his
WAD-file? Or if someone (like me presently) is trying to use SDL behind a
C++ driver interface that gives a stream to read the resources from?
The only solution I can see is providing a callback function, like:
typedef size_t (*SDL_ReadFunc)(void *ptr, size_t size, size_t nmemb,
void *data);
Unfortunately, some file formats require being able to seek to a
particular offset. BMP, for one. This isn’t easily accomplished
with a compressed or encrypted file.
Ideas?
BTW, since SDL won’t natively load most file formats, it might be a good
idea to write a separate library to load general file formats, and add
encryption, compression, etc. to that.
BMP, and WAV are natively loaded just to make it easy to start out.
Markus Enzenberger <markus.enzenberger at physik.uni-muenchen.de> writes:
Hello,
Consider it a feature request.
SDL 0.9.5 will have SDL_FPLoadWAV, SDL_FPLoadBMP, SDL_FPSaveBMP, etc.
thanks for your quick response. Actually, I am not sure if FILE* is the
perfect way.What if someone is using a compression or encryption algorithm in his
WAD-file? Or if someone (like me presently) is trying to use SDL behind a
C++ driver interface that gives a stream to read the resources from?The only solution I can see is providing a callback function, like:
typedef size_t (*SDL_ReadFunc)(void *ptr, size_t size, size_t nmemb,
void *data);SDL_AudioSpec SDL_LoadWAV(SDL_ReadFunc func, void func_data,
SDL_AudioSpec *spec,
Uint8 **audio_buf,Uint32 *audio_len);/* Example for a callback function reading from a file: */
size_t FileRead(void ptr, size_t size, size_t nmemb, void data)
{
FILE file = (FILE) data;
return fread(ptr, size, nmemb, file);
}
yes I agree, in places i read in a buffer of my own compressed data
and would like to just hand over a pointer to the uncompressed data
j
What if someone is using a compression or encryption algorithm in his
WAD-file? Or if someone (like me presently) is trying to use SDL behind a
C++ driver interface that gives a stream to read the resources from?The only solution I can see is providing a callback function, like:
typedef size_t (*SDL_ReadFunc)(void *ptr, size_t size, size_t nmemb,
void *data);Unfortunately, some file formats require being able to seek to a
particular offset. BMP, for one. This isn’t easily accomplished
with a compressed or encrypted file.Ideas?
Just being able to load from FILEs would be enough. Adding callback
functions, etc, seems a bit messy to me, and goes against the S in SDL.
If people really want fancy compressed formats, they could create a pipe
and a thread to feed it. (or would this be too inefficient?)On Sat, 3 Oct 1998, Sam Lantinga wrote:
-----------------------------------------*-
Paul Harrison - BSc student, Monash Clayton
Homepage: http://yoyo.cc.monash.edu.au/~pfh
Weirdness always increases… exponentially
Just being able to load from FILEs would be enough. Adding callback
functions, etc, seems a bit messy to me, and goes against the S in SDL.
You are right. Maybe SDL should not deal with loading (and converting)
resources at all. Loading a WAV file is not platform dependent,
so it could well go to an extra library, like Sam proposed.
If people really want fancy compressed formats, they could create a pipe
and a thread to feed it. (or would this be too inefficient?)
That is a good idea, covering all needs. On the other hand, as far as
I know, it would not work on Windows. So your code would no longer be
portable.
See you
Just being able to load from FILEs would be enough. Adding callback
functions, etc, seems a bit messy to me, and goes against the S in SDL.
You are right. Maybe SDL should not deal with loading (and converting)
resources at all. Loading a WAV file is not platform dependent,
so it could well go to an extra library, like Sam proposed.
Well, I agree that SDL should be kept as light-weight as possible, but
as Sam said, loading BMPs and WAVs helps people (like me) who don’t
want to muck around with writing their own loaders, and knowing the
internals of the SDL media formats. Personally, I’d like to see
something that can be dropped into SDL that will load arbitrary files
from other files (Perhaps using a callback function to handle the
nitty-gritty of file encryption/compression), but I don’t have the
talent to write it myself. It’s a catch-22.
If people really want fancy compressed formats, they could create a pipe
and a thread to feed it. (or would this be too inefficient?)
That is a good idea, covering all needs. On the other hand, as far as
I know, it would not work on Windows. So your code would no longer be
portable.
I really don’t understand why it wouldn’t work on Windows. I mean, WAV
and BMP files are first and foremost data files, and should be readable
by FREAD and such.On 4 Oct, Markus Enzenberger wrote:
–
| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/
Well, I agree that SDL should be kept as light-weight as possible, but
as Sam said, loading BMPs and WAVs helps people (like me) who don’t
want to muck around with writing their own loaders, and knowing the
internals of the SDL media formats. Personally, I’d like to see
something that can be dropped into SDL that will load arbitrary files
from other files (Perhaps using a callback function to handle the
nitty-gritty of file encryption/compression), but I don’t have the
talent to write it myself. It’s a catch-22.
It is a catch-22, and this sort of thing is a perfect candidate for the
examples and demos archive. 
PenguinPlay, http://sunsite.auc.dk/penguinplay/, is trying to be a general
game development platform, much more high level than SDL, but they are
trying to do things like create general file loading routines and so forth.
They are a work in progress, so as far as I know they don’t have any usable
code yet, but I’ll CC this to the PenguinPlay list and let them comment.
If people really want fancy compressed formats, they could create a pipe
and a thread to feed it. (or would this be too inefficient?)
That is a good idea, covering all needs. On the other hand, as far as
I know, it would not work on Windows. So your code would no longer be
portable.
I really don’t understand why it wouldn’t work on Windows. I mean, WAV
and BMP files are first and foremost data files, and should be readable
by FREAD and such.
I think he was referring to the use of a thread as a general data source,
and yes, this can be done with any OS that has a decent level of thread
support. You could do this on all of Linux/Win32/BeOS, but you’d still
have the problem of not being able to seek within the datastream, unless
you send a “seek” message to the thread and let it sort out the details.
It would also allow you to do “asynchronous” I/O, in which you can ask it
to read large files from disk and continue, say, data structure initialization.
It’s an interesting idea.