As far as I understand, this tends to happen with low framerates. The player's weapon sounds (and other viewer-local sounds) are played at the player actor's position, which is normally set the same as or close enough to the listener/camera position that it knows to play the sound centered. But, the engine seems to start a sound using the old listener position and the new actor position (or vice-versa, the new listener position with the old actor position), causing a sound to start off-center if the player's moving, and the engine's not able to re-sync their positions until the next audio update. Either that, or the sound is started using a different offset than what it gets updated with. Regardless, if there's then a large enough time gap between the sound starting and the next audio update, the sound will start playing off-center before re-centering on the next audio update.
I've not dug very deep into GZDoom's frame update loop to figure out how to fix this, or if it's even possible to fix without refactoring the update logic to ensure the actor and listener are both in their updated/final positions prior to starting sounds (or changing how viewer-local sounds are tracked), which may or may not create compatibility issues with existing content.
I've not dug very deep into GZDoom's frame update loop to figure out how to fix this, or if it's even possible to fix without refactoring the update logic to ensure the actor and listener are both in their updated/final positions prior to starting sounds (or changing how viewer-local sounds are tracked), which may or may not create compatibility issues with existing content.
Statistics: Posted by Chris — Sun Oct 06, 2024 10:42 am
