[Openal-devel] draft 1.1 spec v1.4 up
garinh at cheesetoast.net
Mon Feb 28 11:34:44 PST 2005
> a) Why do we have separate types for ALC at all? What's e.g. the
> difference between an ALint and an ALCint? IMHO the AL types alone
> should be enough.
I don't think it's really necessary, but of course we'll keep the same
setup for 1.1 since that's the way it was for 1.0.
> b) 6.2.1: The context attributes should be explained a little bit,
> having only a one-liner is not sufficient at all to understand what
> they are for.
Good point -- I'll take a look at expanding that section.
> c) 6.2.2: What does alcCreateContext return in case of an error?
> NULL, I guess, but that's not specified.
I'll make that explicit.
> d) 6.2.2: Allowing NULL as an attrList for alcCreateContext has a
> tendency to allow buggy code to proceed without notice. An empty list
> should only be represented by a pointer to zero, so an
> ALC_INVALID_VALUE might be more appropriate.
I don't think this can change without creating compatibility issues.
> e) 6.2.5: alcSuspendContext returns void.
> f) 6.3.3: Requiring alcIsExtensionPresent before an extension can
> actually be used is a real hack (and probably only caused by buggy
> implementations in the field). Testing and initializing an extension
> are fundamentally different issues, and they should be kept separate,
> otherwise we should rename this to "alcInitializeExtension". :-]
> Getting an entry point via alcGetProcAddress should be enough to use
> that entry point. Implementations can easily delay initialization
> until that call or the first use of that entry point.
I don't have strong feelings on this -- so I'm fine with eliminating
any comments about the implementation doing initialization of an
extension when it is requested. In practice, it may actually be
convenient for the implementation to do _some_ initialization when the
IsExtensionPresent call is made, however. An example is Ogg Vorbis.
The implementation won't know that it can handle Ogg Vorbis until it
asks for the appropriate library support, and it might as well keep the
pointers around for later use once it has asked... Of course, that
isn't required -- as you point out, the implementation can do all this
on first use of the extension.
> g) 6.3.3: Specifying upper case as the canonical extension name seems
> odd. What's wrong with mixed upper/lower case? IIRC, glXGetProcAddress
> *is* case sensitive, and we try to mirror common OpenGL behaviour.
I don't really care. The problem is that we have had some done in all
uppers and some with mixed case over time. I decided to try to make
things simple by just saying that extension queries for 1.1 are
case-insensitive and declaring everything as all-upper-case in the
spec. I only did that because I think it looks better, that's all. If
a specific programmer is more comfortable with mixed-case, it would
still work fine.
> h) 6.3.3: Why is a NULL extName not an error? Again, this has a
> tendency to hide programming errors.
I suppose we could make at an INVALID_NAME error. I don't think that
would cause any problems, and would reflect that an unusable name was
Another thing I need to re-check -- I haven't prefixed all the error
codes with AL_ or ALC_ yet...
> i) 6.3.5: I think the concept of al(c)GetEnumValue is broken and
> fundamentally different from the OpenGL way of handling this: If
> al(c)IsExtensionPresent tells me that an extension is actually
> supported, why should I bother to query the corresponding token
> values? Having a central registry for the token values (just like
> OpenGL does) is the right way IMHO. Keep it simple! Furthermore, it
> complicates the task for non-C language bindings for OpenAL.
That's the way things are normally done as far as I know. But if you
don't have a header or want to make one which contains the codes, then
al(c)GetEnumValue allows you to get them. There is a central registry
on the OpenAL site (which I think is pretty much current).
> j) 6.3.5: If al(c)GetEnumValue stays in the spec, it should at least
> return an AL(C)enum, not a uint.
That seems to make sense.
> k) 6.3.6: I guess that the ALC error flag should be set to
> ALC_NO_ERROR after a call to alcGetError.
> l) 6.3.6: OpenGL allows for distributed implementations and therefore
> allows multiple error flags. Shouldn't we allow this, too?
Seeking feedback from others on this one... I can't say I have thought
through the implications.
> m) 6.3.7: It might be clearer to say that the deviceHandle is ignored
> for an ALC_DEFAULT_DEVICE_SPECIFIER query than to say that NULL is
I'll try to reword that without putting anyone in a position where they
might put the wrong value in there...
> The remarks about extensions hold for appendix 7, too. Furthermore,
> 7.1 shouldn't mention alcGetProcAddress.
Thanks for all the input...
More information about the Openal-devel