[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