Major API change for SDL 0.9.11

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?

0.9.11:
SDL now has a data source abstraction which can encompass a file,
an area of memory, or any custom object you can envision. It uses
these abstractions, SDL_RWops, in the endian read/write functions,
and the built-in WAV and BMP file loaders. This means you can load
WAV chunks from memory mapped files, compressed archives, network
pipes, or anything else that has a data read abstraction.

    There are three built-in data source abstractions:
            SDL_RWFromFile(), SDL_RWFromFP(), SDL_RWFromMem()
    along with a generic data source allocation function:
            SDL_AllocRW()
    These data sources can be used like stdio file pointers with the
    following convenience functions:
            SDL_RWseek(), SDL_RWread(), SDL_RWwrite(), SDL_RWclose()
    These functions are defined in the new header file "SDL_rwops.h"
    
    The endian swapping functions have been turned into macros for speed.
    
    The endian read/write functions now take an SDL_RWops pointer
    instead of a stdio FILE pointer, to support the new data source
    abstraction.

    The SDL_*LoadWAV() functions have been replaced with a single
    SDL_LoadWAV() function that takes a SDL_RWops pointer as it's
    first parameter, and a flag whether or not to automatically
    free it as the second parameter.  You can still load WAV files
    in one line:
            SDL_LoadWAV(SDL_RWFromFile("sample.wav", "rb"), 1, ...);
    The SDL_LoadWAV() function will close the opened file automatically.

    The SDL_*LoadBMP() functions have been replaced with a single
    SDL_LoadBMP() function that takes a SDL_RWops pointer as it's
    first parameter, and a flag whether or not to automatically
    free it as the second parameter.  You can still load BMP files
    in one line:
            SDL_LoadBMP(SDL_RWFromFile("sample.bmp", "rb"), 1, ...);
    The SDL_LoadBMP() function will close the opened file automatically.

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

Sam Lantinga wrote:

Comments anybody?

Must resist… urge… to write beautiful… interface/inheritance scheme in
C++…

:wink:

m.–
“We can deny everything, except that we have the possibility of being better.
Simply reflect on that.”
– His Holiness The Dalai Lama

Sam Lantinga wrote:

Comments anybody?

Must resist… urge… to write beautiful… interface/inheritance scheme in
C++…

grin Me too. :slight_smile:
But we must not succumb! :slight_smile:

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

Sam Lantinga wrote:

Hey, when are you coming to work for us? :slight_smile:

I hope to start June 1st. Spoke to Scott about the details today. I fear I
have been classified as “picky” about housing. Ah well…

Hacking out the thesis right now, actually writing an interface in C++ for
plug-in error metrics for the mesh reduction… the messiest data structures I
have ever had the fortune to work with. Since it’s late and I have no one to
talk to about my work, here you go:

Imagine a mesh structure vaguely like this:

|–^--/|
| /_/ |
| /\ /\ |
|/Y|

The data structures are roughly:

a) vertices, which have pointers to the edges they are attached to
b) edges, which have pointers to the 2 vertices that compose them, and
pointers to the faces they are attached to
c) faces, which have pointers to the 3 edges that compose them
d) a priority queue of all the edges so that we can get the least cost edge in
O(1) time

When the middle edge is collapsed, we have to

  1. remove the edge from the two vertices, v0 and v1
  2. unattach the newly degenerate faces from the edges it uses, and delete them
  3. create a new vertex v’ using v0 and v1
  4. reattach the edges previously connected to v0 and v1 to v’
  5. remove duplicate edges generated in the collapse operation
  6. remove degenerate edges generated in the collapse operation
  7. mark those edges affected in teh operation as invalid so that their metric
    can be recalculated when they are popped off the queue

Ah, that feels better. The neat thing is that it’s all done with templates and
the STL/algorithm library. Which has so far been faster than my own custom
made data structures. I think it might have to do with a slab allocator that
avoids memory fragmentation that you get from all those little tree/queue
nodes…

BTW, did you read the horrid article on Next-Gen online today about Linux/SGI
as the dev platform for the PSX? That ferrari comment? WTF? I also interpreted
the Sony rep’s comment as an attack at MS, not Linux… sigh…

m.–
“We can deny everything, except that we have the possibility of being better.
Simply reflect on that.”
– His Holiness The Dalai Lama

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?

I definitely like this :slight_smile:

There is one point however with waves:

Memory consumption can become quite high, if you have high quality sound
and a large number sound sources. It could be desirable not to load them
into memory completely for saving memory and avoiding jerks if loading is
done synchronously within a single frame.

On could use some kind of streaming instead. Why not split SDL_LoadWAV_RW
into 3 functions:

SDL_OpenWAV opens a data source and returns a handle,
SDL_ReadWAV reads a number of bytes to an audio buffer (with a looped
flag, if the sound source should be played looped),
SDL_CloseWAV closes the data source.

See you

  • Markus

Sam Lantinga wrote:

Comments anybody?

0.9.11:
SDL now has a data source abstraction which can encompass a file,
an area of memory, or any custom object you can envision. It uses

Haven’t you given this release a wrong name on the download section
of your homepage? I see the usual 0.9.9 version and a version 0.8.11
from 21st of februrary 1999…

BTW - I’m having problems with v0.9.9 crashing on NT when I use
audio - I’m going to try 0.9.11 now…

Cheers–
val it = ("?NOQ of the Sun", “Johnny Andersen”,
[“anoq at vip.cybercity.dk”, “anoq at berlin-consortium.org”,
“anoq at diku.dk”], “http://users.cybercity.dk/~ccc25861/”)
: cyberspacename * meatspacename * email list * homepage URL

ANOQ of the Sun wrote:

Haven’t you given this release a wrong name on the download section
of your homepage? I see the usual 0.9.9 version and a version 0.8.11
from 21st of februrary 1999…

OK, I guess it was not the homepage, it seems to be an older release…sorry.

BTW - I’m having problems with v0.9.9 crashing on NT when I use
audio - I’m going to try 0.9.11 now…

Do you know if / when there will be a new Win32(GCC) release withthis problem
fixed? The application crashes when it shuts down -
the aliens demo has the same problem.

However I noticed that the HELLiZER demo, using v0.8.something,
does not crash even though it uses audio - but it plays MIDI,
not WAV-files - I don’t know if that’s a difference…

Cheers–
val it = ("?NOQ of the Sun", “Johnny Andersen”,
[“anoq at vip.cybercity.dk”, “anoq at berlin-consortium.org”,
“anoq at diku.dk”], “http://users.cybercity.dk/~ccc25861/”)
: cyberspacename * meatspacename * email list * homepage URL

Do you know if / when there will be a new Win32(GCC) release withthis problem
fixed? The application crashes when it shuts down -
the aliens demo has the same problem.

I need to spend some time fixing the audio in SDL 0.9 for Win32.
I don’t know what happened, but it’s broken now.
If you find anything, please let me know.

However I noticed that the HELLiZER demo, using v0.8.something,
does not crash even though it uses audio - but it plays MIDI,
not WAV-files - I don’t know if that’s a difference…

No, HELLiZER plays MOD, and uses the SDL mixer library to do so.
I bet if you compile it with SDL 0.9, it will crash too.

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

Sam Lantinga wrote:

I need to spend some time fixing the audio in SDL 0.9 for Win32.
I don’t know what happened, but it’s broken now.
If you find anything, please let me know.

I found out a few things:

SDL_0.8.11 also crashes on shutdown just like 0.9.9 -
and 0.8.11 is supposed to be the stable one? :slight_smile:

But I found a quick and dirty solution:
I just omit the call to SDL_CloseAudio and
everything seems to work perfectly on NT,
so the problem must be triggered in that function.
I will have to verify if it works on 95
too…

Cheers–
val it = ("?NOQ of the Sun", “Johnny Andersen”,
[“anoq at vip.cybercity.dk”, “anoq at berlin-consortium.org”,
“anoq at diku.dk”], “http://users.cybercity.dk/~ccc25861/”)
: cyberspacename * meatspacename * email list * homepage URL

There is one point however with waves:

Memory consumption can become quite high, if you have high quality sound
and a large number sound sources. It could be desirable not to load them
into memory completely for saving memory and avoiding jerks if loading is
done synchronously within a single frame.

On could use some kind of streaming instead. Why not split SDL_LoadWAV_RW
into 3 functions:

SDL_OpenWAV opens a data source and returns a handle,
SDL_ReadWAV reads a number of bytes to an audio buffer (with a looped
flag, if the sound source should be played looped),
SDL_CloseWAV closes the data source.

You are always welcome to implement something like this in your own code.
The WAV and BMP functions in SDL are just meant as simple convenience
functions. If they don’t meet your needs, just make something that does. :slight_smile:

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

You are always welcome to implement something like this in your own code.
The WAV and BMP functions in SDL are just meant as simple convenience
functions. If they don’t meet your needs, just make something that does. :slight_smile:

Maybe it might be a good idea to move the wav and bmp file loaders into the
demo archive, as examples of using SDL_OpenWav and SDL_ReadWav etc.

That way, it will provide the functionality to those who need it, and leave it
open to variation. (Remember, in many cases it is obligatory for programs to
maintain compatability with the main library, according to the LGPL)

Just a thought, anyway.On Mon, Mar 29, 1999 at 02:47:58AM -0800, Sam Lantinga wrote:


– Michael Samuel

You are always welcome to implement something like this in your own code.
The WAV and BMP functions in SDL are just meant as simple convenience
functions. If they don’t meet your needs, just make something that does. :slight_smile:

Maybe it might be a good idea to move the wav and bmp file loaders into the
demo archive, as examples of using SDL_OpenWav and SDL_ReadWav etc.

Maybe, but all the test programs use the functionality, so I figured
a single simple image and sound loader would be useful to have in the
main library.

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software> On Mon, Mar 29, 1999 at 02:47:58AM -0800, Sam Lantinga wrote:

Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/