[Openal-devel] Extension proposal updated

[Chris Robinson]

Just poking about these extensions since I haven't heard a response or 
anything for a couple weeks..


On Friday 19 September 2008 08:11:45 am Daniel PEACOCK wrote:
> Hi Chris,
>
> I don't really like the fact that each Attenuation Table needs a new enum
> value, or that there should be any limit on the number you can create,
> apart from memory.
>
> So how about ...
>
> We treat an Attenuation Table as an object ...
>
> alGenAttenuationTables(ALsizei n, ALuint *tables);
> alDeleteAttenuationTables(ALsizei n, ALuint *tables);
> alIsAttenuationTable(ALuint table);
>
> The IDs returned will be assigned by the implementation, which will be
> responsible for using values that do not collide with the standard defined
> enum values for the distance models (AL_NONE, AL_INVERSE_DISTANCE_CLAMPED,
> etc ...)

I actually thought of that, a bit before sending the updated proposal. 
However, it breaks the paradigm of the other objects that are handled the 
same way (sources, buffers, effects, filters, auxilliary effect slots, etc). 
Instead of having the same set of functions:
alGen*s
alDelete*s
alIs*
al*[3]{i,f}[v]
alGet*[3]{i,f}[v]

It would just share the first three, then go off on its own. Plus, OpenAL Soft 
(and I imagine wrap_oal.dll, assuming it hasn't changed that much since 
closing up) use direct pointers for the object handles, at least in 32-bit.. 
so there's not much room to move around with if it happens to generate a 
pointer that's the same as an enum. Plus, new extensions may add new enums, 
which an app could look for but the implementation might not.. so you could 
get:

alGenAttenuationTables(1, &table);
alAttenuationTable(table, foo, bar);

alDistanceModel(table);
...
ALint model = alGetInteger(AL_DISTANCE_MODEL);
if(model == AL_SOME_CRAZY_EXTENSION_ENUM)
   ...

There's no way an implementation could protect against that if the table id's 
are generated at run-time and it doesn't implement/know about that extension.

IMO, the tables feel more like they're predefined properties of the context 
that you set as "current" for a distance model, not specific objects you 
create/destroy as you need. Though I agree in that I don't like the limitting 
factor inherent of taking an enum range, but I'm not sure what else to do 
since they pretty much are enum values and must not clash with other enums 
(at least as far as alDistanceModel and any other function that can handle 
such enums are concerned).

> In this formula ...
>
> entry = AL_ROLLOFF_FACTOR * (distance–AL_REFERENCE_DISTANCE) /
>                 (AL_MAX_DISTANCE–AL_REFERENCE_DISTANCE) *
>                 (AL_ATTENUATION_TABLE_SIZE_EXT-1);
>
> entry will need to be clamped in range here (AL_ROLLOFF_FACTOR can be > 1)
>
>         gain = AttenuationTable[entry]

Right.. originally had it where the entry was clamped to 0 and max, but then 
thought that it was already distance clamped so couldn't be <0 or >1.. but I 
missed the rolloff factor :P

> ISSUES ... ALuint, ALint and ALenum are being used inter-changeably (sp?).
> Is that OK?  Are they always the same size (32bit) on all platforms?

ALuint and ALint should always be the same size. At least, OpenAL already 
assumes this since you can get buffer id's, an ALuint, via alGetSourcei, 
which stores in an ALint*. In the headers I have, at least, ALenum is a 
typedef of an int, which is the same as ALint.. so as long as that remains 
true, it should always be true that sizeof(ALenum) == sizeof(ALint).