openal-soft icon indicating copy to clipboard operation
openal-soft copied to clipboard

Add and fix function declaration constants for extension functions

Open hypatia-of-sva opened this issue 11 months ago • 3 comments

We were looking through alext.h and noticed some discrepencies with how the functions of some extensions were defined, by either missing or wrong constants. This has mostly no effect, since they resolve either to the same value or an empty extern declaration anyway, but we thought it should be cleaned up to make them more uniform between extension and the direct and non-direct functions.

hypatia-of-sva avatar Mar 29 '25 12:03 hypatia-of-sva

Also, is it intentional that the doppler factor function has a "direct" version, but doppler velocity not?

hypatia-of-sva avatar Mar 29 '25 16:03 hypatia-of-sva

Adding AL_API/ALC_API to extension functions in the header may cause them to be exported as normal symbols from the library, when those functions should be retrieved dynamically with al[c]GetProcAddress after checking the extension is supported rather than used directly. If the extension is ever removed (not that I expect them to be, very few completed extensions have been), removing the functions would break ABI since apps could've linked to the symbols directly and will fail to load, even if they don't call it without the extension. I have mistakenly done this with many extension functions (particularly older ones), even some in-progress extensions that I ended up abandoning or removing functions from, and has resulted in needing to leave dummy functions that do nothing but set an error.

Also, is it intentional that the doppler factor function has a "direct" version, but doppler velocity not?

Yes, alDopplerVelocity and AL_DOPPLER_VELOCITY are deprecated in OpenAL 1.1, because they weren't well-defined in 1.0 and different implementations behaved somewhat differently (I'm guessing the velocity-to-pitch algorithm wasn't defined or very clear, so different implementations did it differently, and how the doppler velocity influenced the resulting pitch depended on how it was done). They were replaced with alSpeedOfSound and AL_SPEED_OF_SOUND, which has more well-defined behavior.

A 1.1 implementation can still implement alDopplerVelocity and AL_DOPPLER_VELOCITY for compatibility with 1.0 apps, as OpenAL Soft does (where functionally, alDopplerVelocity(x) -> alSpeedOfSound(x * 343.3f) and alGetFloat(AL_DOPPLER_VELOCITY) -> alGetFloat(AL_SPEED_OF_SOUND) / 343.3f, as suggested by the 1.1 spec), but there's no reason to use them in an app targeting the 1.1 API, so there's no reason for a alDopplerVelocityDirect function. OpenAL Soft even invokes a deprecation message through AL_EXT_debug when alDopplerVelocity or AL_DOPPLER_VELOCITY are used.

kcat avatar Mar 29 '25 21:03 kcat

Okay, yes, that makes a lot of sense. Then I guess the only thing from the PR is the change to the right noexcept macro, and I doubt that has any priority, so I think it makes the most sense to close this PR for now

hypatia-of-sva avatar Mar 30 '25 01:03 hypatia-of-sva