VIS optimization also affects in-game sounds. It's this way since Q3A, but is it expected?
The-Gig opened this issue · 3 comments
While doing some tests about a bug where target_speaker sounds are abruptly stopped due to VIS optimization in OpenAL mode (#78), I noticed that VIS optimization also blocks in-game sounds (e.g. grenades bouncing and exploding), but in this case it's not an OpenAL-specific issue, it's a behavior since the original Q3A binaries. This one does not affect target_speaker.
So, I wonder whether it's meant to be this way as part of the optimization (e.g. to reduce network traffic - but I have no idea whether the server considers this stuff or not) or it's just an overisight by id software.
While the other one is certainly a bug, I don't know whether this one should be "fixed" or not... I mean, on one side I see no reason why I should turn around a column and stop hearing the footsteps and shots of my opponent which may still be just 1 meter away from me... on the other side, an updated engine might provide a slight but unfair advantage over those using classic engine.
Any thoughts?
audiotest.zip
Attached, a test map (compiled with and without VIS phase) I made which allows to test both issues. Includes a readme file where I explain the tests in more detail. It's gplv2+.
Probably worth to note is that Q3 had very basic sound support. In opposite to later titles (based on idtech3), Q3 never supported different sound ranges/distances. Thats bad. Just imagine you play all the sounds even if they are behind a wall, for example an explosion, than footsteps and all other dynamic sounds are played as well, and you have no real opportunity to determine how far the sound will be hearable. It would be very noisy. Later games like ET have a few more parameters to determine range and volume. Q3 didn't offer these values. The engine (API) is very limited in this regard, though you can 'fake' more silent sounds by play two differnt sounds per distance (mod sided), RtCW did this for dynamte iirc.
Adding those parameters to the API was planned for Spearmint (zturtleman/spearmint#162) and it worked well in my own fork. As far as OpenArena is concerned it's hard to find any good solution I think.
However, in these days when people like to see enemies behind walls, it might be worth helping them play the game by not only noticing the enemies with arrows, flashing shaders etc, but even with sounds ;)
Tobias, I just tried that in the original Q3 engine. Ambient sounds (or at least target_speaker) actually fade in/out as you get closer/farther to their origin, but in-game sounds like explosions are played at full volume until they are too far and they disappear completely all of a sudden. So there, in-game sounds there are blocked by both VIS and an invisible "sphere" of a certain diameter around you, I guess.
In OpenArena, instead, in-game sounds are abrutply blocked by VIS, but fade gently by sheer distance.
Yes. Unfortunately I don't know how to fix this situation concerning an engine that should stay compatible to vanilla Q3a mods.
Changing the API would fix things, but is pointless. Hacking the distance like the RtCW dynamite, eats up resources, because you would have two sounds for the same event (assuming you make all sounds not considering VIS). This is also not very pleasant. Although a solution like in RtCW would be conceivable. The dynamite explosion was audible there so everyone would know the engineer blew up an objective. Anyways, Q3 mods don't really have such 'important' sounds.
In Q3 Team Arena the Kamikaze sound was played globally iirc.
I think it's really a matter of choice, playing all sounds independently from being vis blocked would be not very realistic and too noisy. Blocking all sounds is also not very realistic because even very loud sounds would be vis blocked, which is absurd, if an explosion just happened a few units away from you.
Btw, OpenAL has some cvars to set the distance at when sounds start fading (min/max), and a rollof factor: https://github.com/OpenArena/engine/blob/master/code/client/snd_openal.c#L647. Unfortunately this is applied to ALL sounds, not independently for each sound. So the "diameter" you mention will either increase or decrease.
SDL doesn't have an equivalent iirc.
Additional info: If you want to dig into the current sound engine(s), be aware that the sound channels system is broken as well, which don't really help much. The channels system can be used to fix this issue as well (for example to favor/play CHAN_WEAPON sounds louder than others).