[Openal-devel] Faster buffer model, and more random stuff

[Sherief N. Farouk]

> > The "vagueness" of a just-created buffer is similar to the vagueness of a
> > just-created texture in GL. It creates the object, but doesn't allocate
> > any storage for it, which is what alBufferData is for.
>
> And GL people realized this is A Bad Idea, and they moved away from it for
> GL 3.0. In GL 3.0, a texture has its dimensions and type specified on
> creation and are immutable attributes.

I'm not too sure how I feel about that. I like being able to reuse buffers by 
specifying a new size/format without having to destroy/recreate it. Some 
audio sources can also work with variable length input streams (eg. capture, 
or a real-time network audio stream), and forcing a specific buffer size 
would cause problems. And when dealing with end-of-stream where you might not 
even have enough to fill a buffer...

>>: Here're the 2 possible scenarios I thought of here:
1) The high performance game using several small buffers per source to stream OGG, say: Creating the buffers with specifying fixed sizes allows for some optimization, and when the driver knows that this buffer won't exceed a certain limit it can more easily determine to put it in HW. End of stream could be zeroing-out.

2) The non-bleeding edge program loading a whole file and playing it:
In this case, the performance difference between destroying and recreating on a good driver shouldn't be much of an issue. Remember how the MapBuffer ideology allows for lazy and async operations.

- Sherief