[Openal-devel] Map/Unmap API

[Chris Robinson]

On Monday 17 August 2009 12:01:07 am E. Wing wrote:
> Conceptually, how do see this extension in comparison to the
> alBufferDataStatic extension that Apple and Creative Labs/Xbox 360 (I
> hear) support? If they overlap, perhaps their terminology needs to be
> factored in?

alBufferDataStatic lets the implementation/mixer use the app's data directly, 
avoiding copies all together. Databuffers are simply OpenAL-controlled 
storage, that in this extension in particular can be used for efficient 
copying through alBufferData.

The latter leaves more flexibility with the OpenAL implementation since it can 
continue using implementation-defined internal storage for Buffers (eg. always 
convert to 16-bit, on dedicated hardware, etc), while buffer_data_static 
requires the implementation to handle the data as-is.


I can also see databuffers being re-used for other things in the future. 
Perhaps as a way to quickly update a number of sources' parameters, eg. one 
buffer to hold a list of source IDs, and another buffer to hold property data, 
then to send them and have it all update at once:

databuffer1:
ALuint = { sID1, sID2, sID4 }

databuffer2:
ALfloat = { xpos, ypos, zpos, gain,  xpos, ypos, zpos, gain,
            xpos, ypos, zpos, gain }

ALenum attribs[] = { AL_POSITION, AL_GAIN, 0 };

alSelectDatabufferEXT(AL_SOURCE_ID, databuffer1);
alSelectDatabufferEXT(AL_SOURCE_VALUES, databuffer2);

alMultiSourcefv(number_of_sIDs, (void*)0/*from source_id*/, attribs,
                (void*)0/*from source_values*/);

Then sources sID1, sID2, and sID4 would have their positions and gains updated 
in one shot. The existing Playv/Stopv/Pausev/Rewindv functions could also work 
with the AL_SOURCE_ID target.

But that was just an off-the-top-of-my-head idea. Would need some further 
thinking to get it useful (particularly updating the listener at the same 
time).