[Openal-devel] draft 1.1 spec v1.4 up
Sven.Panne at aedion.de
Wed Mar 2 01:40:29 PST 2005
Brian Matzon wrote:
> Garin Hiebert wrote:
>> I just posted a new draft version of the OpenAL 1.1 spec. This one
>> incorporates all the feedback I've received over the past week and has
>> undergone some editing for consistency in naming conventions and
>> layout. Try it out -- it's in the Documentation section of the website.
> One thing that, unfortunately, doesn't seem to have been "fixed", is the
> ALC_EXT_enumeration extension.
> It still returns a list of devices using a \0 as a seperator. This is a
> really really poor decision, and has been made for the sole reason of
> being able to use alcGetString which returns one string with all devices
> in it.
> Besides the obvious bad decision of using \0 as a seperator, I have some
> very serious problems in implementing this extension in our java
> binding, since I cannot *ever* return a Java string having multiple \0's
> in it. I am unsure about how to fix it, unless we simple choose another
> seperator - though it brings along its own issues. I would however like
> to voice my concern about the current implementation.
Hmmm, the only issue I see here is the strange duality of a single query,
but that's just an aesthetical issue. Regarding the "\0 problem": I fail
to see a real problem here: On the native side, Java only has UTF-8 (almost)
and UCS-2 (almost), so you have to do some kind of conversion natively,
anyway. So a \0 separator seems to be a minor issue. The *real* problem in
my opinion is the encoding: OpenAL basically talks only about bytes, but
not about any encoding. This is not only a problem for Java, but for e.g.
Haskell, too, where characters are Unicode. So the question here is: Which
encoding is used for all those char* (and variations) values?
More information about the Openal-devel