[Openal-devel] OpenAL Driver Selection

Chris Robinson chris.kcat at gmail.com
Tue Jun 17 19:23:12 PDT 2008


On Tuesday 17 June 2008 09:46:07 am Richard Furse wrote:
> I never did get Doom3 working with my OpenAL driver, and now
> I can't find the CD! Are you sure it works? If so, I'll
> persist in my search... I like Enemy Territory too - do you
> know if that can be persuaded?

The OpenAL path likely requires EAX support. Trying to coerce the games to use 
OpenAL in Linux have all failed, regardless of what I do with the config 
settings. I've tried Doom3, Quake4, and ET:QW.

> Yep. This would be ideal. How would the parameters be
> exposed? Strong-typed properties seem the easiest immediate
> suggestion... Maybe there's a way in Windows already? We
> could embed GUI code directly in the DLL, but then there are
> all sorts of compatibility gotchas down the line. Another
> option is to provide a link to a DLL-specific config binary
> (ASIO does things this way I think). Perhaps the ideal might
> be a hybrid between this and strong-typed config.

What I figured would be to "export" some configuration functions from the DLL, 
and have the main configuration panel app GetProcAddress them (not 
hard-reference them to maintain compatibility). There are some apps that can 
do this kind of dialog embedding (ie. draw a dialog on a pre-determined 
surface). I can't quite say how they work, though.

> We could code this up as an OpenAL extension through the
> normal mechanism. Hmmm...

I think the idea would be to keep platform-specific stuff out of OpenAL. Even 
the ALC layer is designed to be platform agnostic. But having it piggy-back 
on the DLL so platform-specific code (eg. a control panel applet) can still 
get it wouldn't be too bad, I don't think.


More information about the Openal-devel mailing list