[openal] Noob questions on oepnAL

[Massimiliano Maini]

On 8 January 2016 at 09:21, Chris Robinson <chris.kcat at gmail.com> wrote:

> On 01/07/2016 05:26 AM, Massimiliano Maini wrote:
>
>> Thanks for the prompt and clear reply Chris. Two side questions:
>>
>> 1. Does OpenAL Soft do something particular for sources that are near to
>> the listener ? I've read around about stuff like MacroFX ...
>>
>
> Not currently. There is the AL_EXT_SOURCE_RADIUS extension that increases
> the apparent "size" of a source, which causes the source's locality to
> decrease as it gets closer to the listener, but this won't be supported
> until 1.18.


Nice ! I had a look at AL_EXT_SOURCE_RADIUS.txt on GitHub: I do understand
the general idea (within the "volume" of the source, provide less
localization), but what does "The source has a raised cosine shape" mean
exactly ?
I know what a raised cosine is, but I can't figure out exactly what this
means for a source in a 3d space.


>
> 2. On windows, I know alsoft.ini is in %AppData% and it works fine. If I
>> have an openAL-based app and I want to force it to use OpenAL Soft with
>> it,
>> I can drop the OpenAL Soft dll (renamed to OpenAL32.dll) in the app
>> folder,
>> and that works fine too. But can I also put the alsoft.ini in the app
>> folder and have this local .ini considered (instead of the "global" one in
>> %AppData") ? Same thing for OpenAL Soft's HRTF folder, can I put in the
>> app's folder ?
>>
>
> Not exactly. But what you can do is set the ALSOFT_CONF environment
> variable to a filename to use as an additional config file, before running
> the app (it doesn't use it instead of the AppData one, but any settings in
> it will override anything in AppData).
>
> For HRTF, OpenAL Soft will search the current working directory (which
> might be the app's directory, depending on how it's run) for mhr files.
> Alternatively, you can try setting the ALSOFT_LOCAL_PATH env var to the
> path you want, which will be used instead of the current directory.


Understood, thanks. I think it would be even better if the .ini had the
same behavior as the mhr files: if there's an ini in the in the currently
directory (potentially the app's directory) use it, else go for the the
other options (env var or %AppData%). Would make it easier to drop OpenAL
Soft into an existing app with a dedicated .ini.

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openal.org/pipermail/openal/attachments/20160108/75bb992a/attachment.html>