[EMAIL PROTECTED] schreef: > Hi, > > First of all, Happy New Year to you all ! > Same to you and every one else ;-)
> Now I guess I have to answer this... > > When I ported that sound code to OpenAL, I first tried to use the > parameters you mentionned (for position, attenuation model etc.). > > Problem was the attenuation didn't sound good (I tested with all > models). It might be due to the OpenAL implementation model I was > using at that time (was under Linux, I don't remember the OpenAL > version, though), or maybe I did something wrong. > This is why the current code has its own attenuation model. > Well at the time of writing I've done some math to compare both formulas (i.e. the current one in the WZ code vs OpenAL's one). When the constants (or actually sound-source settings) are set as I've described them in my previous mail both are mathematically identical. > Reimplementing the sound lib (and using all OpenAL features) is > probably a good idea (if I made a mistake in my first > implementation, it is very unlikely someone else will repeat > it). > If this succeeds, You might want to try setting the velocity > of sound sources (at least fastest ones, like projectiles and > VTOLs) and add the Doppler effect. :) > Yes, I was already keeping the Doppler effect in the back of my mind ;-). Problem is currently that it will be very difficult to implement it using this OpenAL implementation. > Best regards, > Rod > > Selon Giel van Schijndel <[EMAIL PROTECTED]>: > >> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
