[Openal-devel] Re: the future of ALUT

[Stephen J Baker]

Garin Hiebert wrote:

> Here's what the platform situation seems to be on alutLoadWavFile:
> 
> 1)  Windows -- The function has no "special hooks" into core OpenAL  -- 
> It just parses the WAV file and gives you a buffer and buffer  
> information which can be used to make an alBufferData call.  The only  
> thing about this function which isn't cross-platform right now is the  
> "fread" commands -- they'd need minor modifications for other platforms.

...several people have said that they do not believe this code is portable.
(eg endianness issues).

> 2)  MacOS -- The function has no "special hooks" into core OpenAL,  either.
> 
> 3)  Linux -- The function has special hooks and could be replaced by  
> one of the other implementations with very little difficulty.
> 
> **
> ** After reading 50+ emails on this strangely sensitive subject,  what's 
> my opinion on what should be done?
> **
> 
> 1)  I think we should go into all the demo code and remove all  
> dependencies on ALUT for the moment, inserting a short WAV-loading  
> routine into the source code where needed.

It's generally agreed that there is no 'short' WAV loading code.  It's an
ugly format that's hard to parse correctly.

IMHO: WE DO NOT WANT END USERS TO CUT/PASTE THAT CODE - because I guarantee
it'll have bugs in it and will need to be worked on in the future and once
someone has done that, we can't get fixes back into their code.

I strongly feel that this is a very bad idea.

This function MUST be a supported library function somewhere/somehow from
day #1.

> 1a)  We should go through all the Linux examples and clean them up.   I 
> wasn't fully aware before a week ago that these were such a mess.   
> Apparently there are many cases in the Linux sample code where non- core 
> functionality is used without an extension query, and other  weirdness.  
> All this needs to be cleaned up.

Yes...but more than that.  OpenAL is supposed to be a portable standard.
That being the case, why do we need separate Linux and Windows example
programs?  The mere fact of that separation is an admission of failure
and the cause of all this mess in the first place.

> 2) We should decide if we want a new ALUT-like project or if we want  to 
> fix the current ALUT functionality (breaking backwards  compatibility).  
> I think it's generally agreed that if we break  backwards-compatibility, 
> that we will also move ALUT into it's own  library where it hasn't been 
> before (MacOS and Linux).

Yes.  That's the huge question.

I've been oscillating back and forth between the two approaches.

If ALUT becomes a separate project, I believe it would also be necessary
to move *ALL* of the test/example/demo programs into the ALUT distribution
so that the OpenAL distro is *just* the core library (al + alc).  This is
what OpenGL does - and it works.

If you aren't prepared to do that - then ALUT should stay inside OpenAL
to avoid the issue of example programs depending on an external library.

I can't say whether that's a good idea or not...it's more of a cultural
thing than an engineering matter...although being able to release ALUT
on it's own timescale will be useful in it's early life.

> 4)  If the decision in #2 was "fix ALUT and break backwards- 
> compatibility," and if it was decided to keep ALUT in the main AL  tree, 
> then ALUT code can then be added back into the demo code as  desired (I 
> would recommend that it be used only for file loading  initially, since 
> that's where the main "utility" of ALUT is).

Yes - but why have the intermediate step of having the examples running
some non-library WAV loader?  I don't see any advantage to doing that -
but I see plenty of disadvantages.

-----------------------------------------------------------------------
The second law of Frisbee throwing states: "Never precede any maneuver
by a comment more predictive than "Watch this!"...it turns out that
this also applies to writing Fragment Shaders.
-----------------------------------------------------------------------
Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sjbaker at link.com           http://www.link.com
Home: sjbaker1 at airmail.net       http://www.sjbaker.org