Right now, this only supports ambient emitters that loop continuously, like the sound of waves, and it doesn't take into account the FOW. The gain of the emitter depends on how close it is to the camera.
It's going to be placed with a nonbroken version of marker_object_sound.xml in atlas / random mapgen script?
How will we specify the soundfile it plays? Typically all values come predefined with the template, which is also the reason why we only have so few trigger points :/
That thing shouldn't have ownership I guess
Should most likely be const CVector3D& instead of a non-const &.
If you are using emplace pass it the parameters for the ctor you want (or in that case those for aggregate initialization), making it call a copy ctor seems pointless.
I'd indent that lambda, but so far I still haven't found a way to write those (in C++) in a way that doesn't hurt my eyes.
The CmpSoundManager functions could be const (but I didn't do that, because doing that while changing things on that global seemed like lying). Maybe there's a way to do that without the global, eg storing a reference to it in that component, but that also sounds ugly.
GetAmbientEmitterGain should be const.
Is adding multiple emitters for one source entity going to be common, or should we provide another id in those cases, so we can enable/disable specific ones?
Thanks for the comments!
I'm not sure if it should be possible to have multiple emitters for one entity, I think it is design decision and from my point of view I'm really not sure.
The idea is that an ambient emitter can be specified as a SoundGroup in the XML, which could possible specify things like cool-down times or constant looping, but this might need a lot of modifications to SoundGroup.cpp.
Handling FOW for ambient emitters may also be rather non-trivial.
I was mostly wondering if we couldn't simplify the removal function, and in any way the code should either explicitly support multiple emitters per entity, or verify that there is at most one.
(Maybe I should read up on what happened to that unstable_remove proposal from SG14. Roughly the thing that could be done would be checking if we are removing something apart from the last element, if yes moving .back() into that spot, and doing .pop_back(). (Maybe one could move that thing to the same place, but that sounds slightly questionable, read the standard if you want to convince yourself that that is fine (if you do, point me to the relevant parts).))
For FoW/SoD that seems like an issue for all sounds, nay?
Does it make sense to use vector? I didn't find using index here. So you could replace it with list, because erase in vector is O(n).
But it also depends on how often we delete emitter. If not frequently then vector could be enough.