To go along with reverse-z on the other axii. This is only for games that have
position/orientation errors causing top-bottom (or left-right) inversion.
The same as the __ALSOFT_REVERSE_Z env var, but in the config file. Should only
be used for per-game config files (either along side the executable, or setting
the ALSOFT_CONF env var when launching the app).
Based on DirectSound's EAX behavior, committing any EAX property commits *all*
deferred property changes, not just the object being changed. So applying EAX
changes can be handled in one place.
Specifically, AL_[EAX]REVERB_ROOM_ROLLOFF_FACTOR always applies to an inverse
distance rolloff model, where the source's AL_ROOM_ROLLOFF_FACTOR applies to
the selected distance model. Consequently, the normal distance and cone
attenuation only needs to be calculated once for all sends, with the effect's
room rolloff calculated and applied separately.
The idea here is that the initial reverb decay can't become less than the dry
path distance attenuation, as the dry attenuation represents the audio that has
not yet had a chance to start reflecting in the environment. As well, the
reference distance indicates where there is no distance attenuation, with any
initial attenuation set by the environment itself.
So what we do is use the dry path attenuation as the baseline for what's mixed
to the reverb, with the decay rate indicating how much of the remaining room
(non-direct) energy attenuates with distance.
This may be over-complicating it. Other sources hint at a more typical XdB per
doubling of distance, with X varying depending on environment properties (room
size, absorbancy, etc). This could be handled by applying a normal inverse
distance attenuation model, with a rolloff factor generated from the reverb
properties (density, decay rate, etc). Will need more testing and research.
It was only added to try to help DSOAL, and it's not clear if it's even
necessary. But with native EAX API support, it certainly isn't necessary
anymore.
Creative's wrapper driver doesn't handle them through alcGetProcAddress, at
least with a null device. For this to work properly, they'd have to be loaded
per-context instead of per-driver.
Creative's wrapper driver doesn't seem to handle EFX enums for alGetEnumValue,
let alone return values only for what's supported. The only way to check which
filter and effect types it supports is try to set them and check for errors.
GCC complains it can't inline the destructor because it's "unlikely" to be
called and would bloat code size, despite being implicitly defined. Technically
accurate, but rather annoying since it's not explicitly called or defined.
