OpenAL support

[angelic]

So I'm now getting interested in the C++ version - having looked already at the C version which appears to be firmly in maintenance mode (see my other posts to the main forum).

I'm not very familiar with the codebase as yet so don't assume I know anything. In fact, assume I know nothing! :) On top of that, don't assume that this is a definite offer of help, but I'm interested in having a hack and seeing if it lies within my ability range (doubtful given my current exposure to C++ but I'm always up for a challenge...)

One thing I started to look at today is OpenAL and the C++ wrapper openalpp.

From the samples provided with the SDK this looks remarkably simple for e.g. play wavs etc., but what I am missing is a statement of requirements from the Doom engine perspective. I assume there is a proprietary sound format which would need to be passed to OpenAL, and there is some positional data too? Is there any design or technical data on this kind of stuff for me to read over, or can anyone suggest where I should be looking for the current implementation details?

Are OpenAL and openalpp acceptable additional requirements for Legacy? I assume the vision is that this should be something optional.

[ToXiCFLUFF]

Heh, personally I love OpenAL, this'd be cool.

[smite-meister]

Currently the C++ version only has a software sound renderer (quite simple, includes just stereo positioning, fake surround effect, distance attenuation and an unfinished Doppler effect:D)

The sound data is handled by a dedicated sound cache, which can handle all the necessary format conversions. Each 3D sound is accompanied by a source position in 3D space and its velocity vector. These can (and will) change while the sound is playing, so the 3D sounds need to be updated in real time.

Additionally, we have normal stereo sounds, which are used for menu sounds, future HUD and announcer messages etc. They have a certain volume and left/right stereo separation, but nothing more.

You also have to consider the observer, who likewise has a position and a velocity. (Because of splitscreen, we may even have two separate observers. I'm not sure how this should be handled.)

[angelic]

Still sounds reasonably complex to me. Well, I'll have a kick with openalpp at some point and see what happens. Very much not guaranteeing that I can be helpful here, but I'm interested to see.

[Hurdler]

About the C++ wrapper, I don't know about it, so my comment must be taken with that in mind...
But feel free to use the C API if you feel more comfortable with. We use OpenGL for the rendering without any wrapper. The same goes for SDL, so I suppose it's not necessary to use a C++ wrapper for OpenAL if it doesn't make sense other than it's just C++. It must be fast and it must help having a better code design. If those two points are not filled, I think we can keep the C API, and maybe create our own C++ class (or use what we already have) on top of it.

Maybe Ville can give his opinion on that (which will be certainly better than mine, as I'm still C influenced ;))