In my player class I set the 3D listener position to the players current position, then when I play sounds I set they’re position before I play them and also as they are updated.
The issue is that the sounds always play relative to the origin of the world rather than the listener’s position no matter what i do. In the designer the 3D events are set to be Head relative as well.
Another thing that I was wondering about is making the event system Right handed. It says in the documentation that i can initialize the EX system to be right handed, but i haven’t noticed anything about the Event system being able to do that.
- dpalmer asked 8 years ago
[quote:52d31la7]The issue is that the sounds always play relative to the origin of the world rather than the listener’s position no matter what i do.[/quote:52d31la7]
If you are sure that all the positions you are setting are correct, then make sure you are checking the FMOD_RESULT being returned from all your FMOD function calls to make sure an error is being returned. Finally you can load the fev in Event Player/Sandbox and test it there, they both support head relative sounds which should help you determine whether the problem is in the code or the project.
[quote:52d31la7]It says in the documentation that i can initialize the EX system to be right handed, but i haven’t noticed anything about the Event system being able to do that.[/quote:52d31la7]
You can pass FMOD Ex init flags to EventSystem::init, which is how you can set it to be right handed.
I saw that the value returned was an error invalid handle, but I don’t understand what the circumstances are that I’m able to set the position. Currently I just have a check that makes sure that the sound is either ready, playing or has no playing sounds, but the event is still active. That seems to work, but its a bit odd.
Again, thanks, you’ve been a really big help.
- dpalmer answered 8 years ago
[quote:3f8d9c51]I don’t understand what the circumstances are that I’m able to set the position.[/quote:3f8d9c51]
When FMOD returns an error, it means nothing was done internally. So if you’re calling [i:3f8d9c51]set[/i:3f8d9c51] functions and get an error, the properties will be unchanged. If you call [i:3f8d9c51]get[/i:3f8d9c51] functions and an error is returned, the values you get back from FMOD are probably bogus. The best thing to do is have a strict error handling policy so you can catch these kinds of things easily.
something like this:
[code:3f8d9c51]void ERRCHECK(FMOD_RESULT result)
if (result != FMOD_OK)
[b:3f8d9c51]FMOD object handles:[/b:3f8d9c51]
An Event* isn’t actually a pointer it’s a handle. When you call getEvent, FMOD creates a handle which refers to an internal object. Whenever a function is called FMOD converts that handle into an object pointer internally.
[quote:3f8d9c51]I saw that the value returned was an error invalid handle[/quote:3f8d9c51]
Invalid handle means that the FMOD::Event* you are using is invalid.
It generally comes from calling functions on an instance which is:
[b:3f8d9c51]uninitialized[/b:3f8d9c51] (If you call any functions before calling getEvent)
[b:3f8d9c51]stolen[/b:3f8d9c51] (you call getEvent more times than the ‘Max Playbacks’ property of the Event)
Please login first to submit.