🐛 Update/fix Doppler effect for OpenAL 1.1 implementations

[Hiradur]

The doppler effect was already reported as defective in #313. Turns out OpenAL 1.1 changed the way how the doppler effect is handled from OpenAL 1.0. Using the old way did not break the build as demanded by the spec but disabled the effect for at least the OpenAL Soft implementation.

With this small change, the doppler effect works with OpenAL Soft again. I chose to drop support for the OpenAL 1.0 way of setting up the doppler effect since I don't think such old implementations see widespread use anymore.

Anyway, during testing I noticed the effect to be unstable for motor sounds when vehicle become unstable under high force conditions. I don't remember this to be the case from the RoR 0.38 days. I'm not sure if this is because I run RoR in a VM (might introduce timing issues) or use the OpenGL renderer (there were some physics instabilities with OpenGL that were not present with DirectX almost 10 years ago, but they have been fixed back in the day. I'm not sure if there are still any differences between rendering systems).
Also note that the value for alDopplerVelocity seems to have been incorrect all this time, assuming that 1 RoR unit represents 1 meter. The formula for the frequency shift caused by the doppler effect changed with OpenAL 1.1 and if I'm not mistaken, alSpeedOfSound = alDopplerVelocity * 343.3f.

I'd appreciate it if somebody using Windows could test with DirectX and provide feedback. Best way to see if the effect is unstable is by making sharp turns with a fast vehicle (I used Nissan GT-R and BMW E36 Polizei Sedan for testing).

Regardless, It might make sense to make the effect an optional setting, what do you think?

[ohlidalp]

I'll have to look at this. alSpeedOfSounnd() is a suspicious function name. Doppler is a prominent effect that I don't want to have wrong in the game. I don't see any reason for physics stabiliyto affectethis, other than using raw node position without any smoothing, which is silly because sound doesn't need to be millimetre-accurate.

[Hiradur]

Sure, feel free to read the OpenAL 1.1 specification, see section Doppler Shift.
I can visually see that the cars vibrate heavily under high force conditions and I suspect that the noises are bound to nodes that vibrate heavily as well. Due to the quick changes in velocity, the doppler effect sounds unstable in these situations.

[Hiradur]

I added several commits, which:

• set alSpeedOfSound dependent on the medium the listener is in (currently either air or water are supported)
• allow to change the doppler factor from the settings menu, temporarily or permanently from the ingame console as well as from Angelscript

I am not sure if we want to keep the console commands in the final product but they are nice for playing around and debugging.

Currently, the doppler factor is not updated without a restart if the corresponding CVar changes.
I'm new to all the code changes that happened during the last eight years or so. The global message loop and the well documented code were a nice surprise!
Not sure if I missed it, but is there a generic approach to push a message if a CVar changes? I wanted to avoid frequent updates of the doppler factor value in the game loop if the value doesn't change.

[Hiradur]

I am currently considering dropping the console functions and message queuing and simply use CVars for management. The advantage would be to have less code to maintain. The disadvantage would be that the doppler factor would have to be regularly updated even if it didn't change. It probably wouldn't be a big problem but we should consider updating some environmental audio properties only a few times per second should it turn out to be too expensive.

What do you think?

[ohlidalp]

Sorry for taking forever to reply - absolutely go for it, I haven't seen the code yet so I'm not entirely sure what you mean, but either way, just arrange things for your comfort. For recent years I've been the only developer around so the game plumbing has become somewhat stale and there's not clear guidance for extending it. Simply feel free to experiment and break the existing conventions, code can be always refactored and tidied up later. CVars are made to be used per-frame.

[Hiradur]

Even though this is a small change, if you don't mind, I would like to close this in favor of #3182, which is my main working branch for audio now (which already contains this branch).
There, I already dropped the doppler_factor console cmd in f9e26fc.