[Openal-devel] Re: [Openal] OpenAL on Windows - two DLLs? Version numbers?

[dpeacock at creativelabs.com]

Hi Ed,

> Okay... that makes sense.  I think part of my confusion is with the names

> of the VC++ projects and which DLLs they produce.

The project names are a bit confusing, so they should probably be changed.

> Or better yet, it might be good to have a software-only "ref_oal.dll" (or

> "sw_oal.dll") and move the existing D3D-hardware support into a separate
> "d3d_oal.dll"...?

So your request has changed from wanting less DLLs to wanting more ;0)

> After reading through the "Enumeration with OpenAL on
> Windows" doc on the web site, it seems like the only way to really be
sure
> that users are getting the version of OpenAL that I have tested with my
> game is to use approach #3 (include the DLLs in the same directory as the

> game, and be sure to load them directly)... but the doc doesn't mention
> that hardware implementations are still available when using that
approach
> (although I think they are, by the normal mechanism).

If you put the Open AL 'wrapper' (wrap_oal.dll) in your game folder and
load this DLL - then the application will never use any other AL
implementation.  However, you can code your application to either load the
Open AL library from the application folder, or to load an openal32.dll
from the user's path (if available) based on a configuration setting.

> It seems that OpenAL32.dll is dependent on wrap_oal.dll and the app will
> exit immediately with a "missing library" type of error if it's not
> present (i.e. I rename wrap_oal.dll and my game won't run)... is this
> intentional?

The OpenAL32.dll router should not be dependent on wrap_oal.dll - but an AL
application using the Router is dependent on finding at least one AL
implementation - or else nothing can work.  Are you seeing strange
behaviour in this scenario ?

Dan