Just taking a look into the current sound libs.

And of course we're using OpenAL there. So why should we actually when
using OpenAL, erm actually erm, use it????
When looking at lib/sound/openal_track.c:sound_SetObjectPosition() I'm
getting a headache.

Rather than just simply setting the sound-generating object's location
using an OpenAL API call, and let OpenAL handle all the gain and volume
attenuation stuff, this code does the job which OpenAL should do (and is
probably better at considering it uses hardware acceleration where
possible).
That function first calculates the distance between listener and sound
source (Pythagoras like; using a quadratic formula then sqrt) . Then
based upon that it calculates the sound's gain based upon the distance
and tells OpenAL to use that gain. Then it makes a final call to the
OpenAL API to set the position of that sound's source. Since one of the
things sound_InitLibrary() does however that last call won't have any
effect because it disables OpenAL's distance calculation by this call:
> alDistanceModel( AL_NONE );
What I tried to explain here, is that the current sound implementation
only uses OpenAL as a sound mixer (which SDL happens to be capable of
just the same) just for playing different sounds in parallel.

The same distance computation is btw provided by OpenAL when the
distance model is set to AL_LINEAR_DISTANCE and the sound source's
AL_MAX_DISTANCE=1.0, AL_REFERENCE_DISTANCE=0.0 and
AL_ROLLOFF_FACTOR=ATTENUATION_FACTOR (ATTENUATION_FACTOR is currently
defined to 0.0003 which is _very_ low).

Therefore I propose a major overhaul/reimplementation for the sound lib
(probably best in a separate branch). So please give me your pros and
cons to this proposal (or its grounds).

-- 
Giel

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Reply via email to