Problems with sound (moving from SFML 1.6 to 2.1)

[horva]

Hello everybody,

I've been lurking this forums for a while now as I'am coming back and redoing some of our game systems that have been written with SFML...soo my problem :p

First off, I'am gameplay programmer, and I didn't write this code. so my knowledge of it is limited.
So far I have moved and adapted input to SFML 2.1, but audio is a problem.. why??

To better understand the problem, take a look of our game screenshot:
http://www.theredsolstice.com/simplified/images/screen5.jpg

When I scroll away(it's a strategy kind of survival game), sound doesn't reduces how it should:
Minimal distance is 27 meters, attentuation 3.

Once the minimal distance is bypassed, sound from example turret goes from 100% to % :S

It stopped working the moment I moved audio to SFML 2.1
Maybe I changed something I shouldnt, but If i rember correctly there was only function names that had to be adapted.

Any ideas?

This is like a cruical part in our game since now you can hear soldiers and guns 3 screens away and it feels.. aaah awful :S


Thank you!

[Jesper Juhl]

Can't answer your question - sorry. Just wanted to say that, that screenshot looks awesome. I want to play the game based on nothing but that

[Nexus]

I'm not aware of a change of attenuation or minimum distance (as far as I remember, they worked fine when I used them last time with SFML 2.0). Are you sure you haven't introduced a bug elsewhere? Maybe you changed the game's distance metrics? You could try a simple example of sound spatialization to see whether SFML 2.1 works as you expect...

The game looks really good, nice to see SFML used in it!

[horva]

Thanks both of you! :p I should add it to the SFML projects page, I think it has been there once but under different game(5 years of dev :p)

Here, I believe problem either occured here in setDirection(), not sure how?
Or below on the buffer area?

Problem is I really just renamed stuff , nothing to fancy, like from "SetDirection" to "setDirection" :S and all went to hell with the sound.

Bolded things are what I suspect what caused it while changing it...(I didn't change the values, just adopted the functions)

void Composer::setListenerPosition(const vec3 &aPosition)
{
   sf::Listener::setPosition(aPosition.x, 5 /*aPosition.y*/, aPosition.z);
}

int Composer::playSoundInternal( const Res &aSound, const vec3 &aPosition, const bool aUsePosition, const float aVolume, const bool aLoop )
{
       
   sf::Listener::setDirection(0, -1, 0);


       //get sound "sound"

   sf::SoundBuffer* buffer = sound->getSoundBuffer();

   tmp->gSoundPlayer->setBuffer(*buffer);
   tmp->gSoundPlayer->setLoop(aLoop);
   tmp->gSoundPlayer->setVolume(tmp->gVolume * 100.0f * aVolume);

   if (aUsePosition) {
      tmp->gSoundPlayer->setPosition(sf::Vector3f(aPosition.x, 0/*aPosition.y*/, aPosition.z));
   
      tmp->gSoundPlayer->setMinDistance(27.f);
      tmp->gSoundPlayer->setAttenuation(3.f);
      tmp->gSoundPlayer->setRelativeToListener(false);
   }
   else {
      tmp->gSoundPlayer->setRelativeToListener(true);
      tmp->gSoundPlayer->setPosition(sf::Vector3f(0, 0, 0));
   }
}


Main question would be, did anyone have any similar issues happen to him while doing the change?
I wil try to create a simple example but atm. this is like playing with fire due to very complicated process of how everything was written(very old code which if you touch without proper knowledge everything goes to hell and then nobody is happy)

[Nexus]

The listener's direction shouldn't be -Y (down), because then it's the negated listener's up vector, and those two vectors must not be linearly dependent. If you need this coordinate system and rather want to change the up vector than the direction, then you're lucky because I just added this feature to the task tracker, so it will be implemented soon

Otherwise, I only know that the listener's target once changed (absolute position vs direction), but that was long ago. I compiled a list of API changes from SFML 1.6 to 2.0, and highlighted the breaking parts in red. It's not complete, but it might still help you.

[horva]

I don't think the listener direction is an issue or ever was as it was like this from the begining(maybe we are using diff coord system).

I tried putting an absolute position for the Y but that didn't help at all, it just goes from 100 to 0 or vice versa.

But the relative to absolute might just be it.
Fixed sf::Listener's target that was a relative direction instead of an absolute position

Any idea how to resolve it, or if there is any chance to put it back to relative just to test if that's 100% the case?

[Nexus]

I don't think the listener direction is an issue atm.

I do.

Direction is -Y = (0, -1, 0)
Up vector is +Y = (0, +1, 0)

Both vectors are linearly dependent. OpenAL (the underlying audio library) yields undefined behavior in this case, because it cannot create a three-dimensional coordinate system from two linearly dependent vectors. Undefined behavior means that you may have luck and it somehow still works, but it's not guaranteed (although it's unlikely in that case).

[horva]

But it was the same in 1.6 and was working perfectly? Any idea why?

Maybe the relative to absolute affected it so it has gone wild?

I was afraid that would be the case, guess we will have to reroll back to 1.6, we're very close to release on Steam and we cannot have those kind of bugs flying around :S

Any chance when this might get solved? Any estimate is helpful, like week, month etc.?

Thanks

[Nexus]

Any idea why?

Maybe the OpenAL backend was different and somehow recovered from that case. "Undefined behavior" allows an implementation to be "smart" and compensate for user mistakes (I wouldn't call that smart actually).

Maybe the relative to absolute affected it so it has gone wild?

The relative/absolute issue only concerned the fact that in SFML 1.6, you set a target (a point in 3D space) rather than a direction (a vector describing the orientation) for the listener.

Any chance when this might get solved? Any estimate is helpful, like week, month etc.?

There is no bug in SFML, you have to make sure that you're using a coordinate system for sound spatialization that makes sense. What I can do however is implement the up vector if it is crucial for your game, because at the moment you're pretty limited.

How does your coordinate system look?

[horva]

I guess an answer would be, 3D cartesian coord system?

I'am sorry if I seem like a noob(and I am in this area), but we don't have a backend programmer anymore that does stuff like this, and few of us have to pick through old stuff now which is like.. noone has enough experience in that area :S
So I apologize once again, and thank you for your patience so far!

[Nexus]

No, I mean how your axes are oriented. Where do X, Y and Z point in the graphical scene? Probably X and Z axes are in the plane, and +Y is up (skyward)?

For a spatial sound system to work as expected, you need an orthogonal 3D coordinate system, i.e. 3 vectors that are perpendicular to each other. It is usually meaningful to use the same coordinate system for graphics and sound -- it's not required, but it simplifies things.

In that sound coordinate system, you have to place the listener with a position and an orientation. You can imagine the listener as the head of the player in the scene, such that he perceives sounds spatially. Depending on where you place the listener (position) and where he looks at (direction), sounds are received differently. If you want the listener to hear the scene from the player's point of view, it is a good idea to adopt the camera position and orientation.

[horva]

X, west +, east -
Z, north +, south -
Y, up +, down -

Think I might have an idea for solution, thanks
Problem is the result will prob be that the sound will always be coming from one side due to gameplay concept, so that's why the Y was used, to eliminate sound always coming from one side, not sure...
Anyway will study this a bit and let you know the results tomorrow!

[horva]

Yeah I fixed it, I was using it wrong, it is the listener issue, I've just set listener direction to (1,0,1) and it works perfectly, I'am sure I tried something similar the other day and there was some weird sound stuff happening.

I'll add one more question on top of this:

- sometimes my entire PC freezes(everything just stops) while playing our game The Red Solstice and having youtube or something like this on(it's totally random).
Could this in any way be related to SFML(audio/window creating), just asking if anyone had similar problem, because I'am trying to narrow down all posibilities.