Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Mobius on July 11, 2010, 11:34:52 am
-
I know it's a bit controversial for a space sim, but how hard is to delay a sound depending on the distance between the player and the source of the sound itself?
If istantaneous sounds are hard-coded and basically impossible to delay in a conventional way, what about "fooling" the code by telling it to play an empty sound (like our beloved none.wav) and then use a script to play the real sound after x seconds (where x = t = v/d)? If it is too hard to delay all sounds, how about limiting this to explosions and even beams? I believe a "Speed of sound" script would significantly improve the gaming experience by boosting the player's perception of distances.
I'm afraid it wouldn't work properly in multi, but limiting its use to the single player mode is enough.
-
Not a scripting issue.
Also, new sound code has been added to trunk already. See the test builds forum for examples.
-
Does that mean that I don't need a script to feature the speed of sound effect? :confused:
-
No, it means that a) the scripting API can't do what you want it to do at the moment, which b) means someone needs to code something like it in, which of course means that you could just as well do it in a way that doesn't need scripting to do it.
All of which combines to "Not a scripting issue", as it means that someone on the SCP or some other coder needs to make the necessary additions to the engine.
-
Are you sure it can't be done? Would you like to explain it?
I thought it was possible: scripting can manage sounds and it can also check distances between ships. I fail to understand how these features can't be combined... :confused:
-
Yes, BUT: Scripting can't cancel or delay sounds. Which is what you'd need in order to do this properly.
In addition, something like this is better handled directly by the engine and additions to sounds.tbl instead of being handled by scripting (imho, of course).
Third, OpenAL already has functions built in to handle doppler effects and other stuff that is based on the relative positioning of objects in a 3D space. I imagine it would be easier to enhance sounds.tbl than it would be to enhance the scripting API.
-
It kills the purpose of my request, though: that feature is not meant to become mainstream, it's just an hypothetic option people may or may not use. I don't need scripting to cancel istantaneous (and almost certainly hard-coded) sounds: editing sounds.tbl would be enough.
Here's an example. All these entries in sounds.tbl...
[...]
$Name: 6 breakup.wav, 0, 0.60, 1, 100, 800 ; ship death roll (3d sound)
[...]
$Name: 7 boom_3.wav, 0, 0.90, 2, 600, 1200 ; * ship explosion 1 (3d sound)
[...]
$Name: 49 boom_1.wav, 0, 0.90, 1, 600, 1200 ; * ship explosion 2 (3d sound)
[...]
$Name: 59 atomic.wav, 0, 0.90, 1, 2000, 4000 ; * captial ship explosion (3d sound)
[...]
...would all have their sound filenames changed to "none.wav". At that point, playing the delayed sounds would be up to the script (time delay = speed of sound / distance). I'm not a coder and, without considering who knows how many hours I spent working on an alternate version (which isn't that great) of Wanderer's flashy deaths, I've never ventured deeper into scripting... so please correct me if I got it wrong. :)
That said (and no offense here!), I believe you rushed a thread move which probably wasn't necessary. :sigh:
-
I would still argue that an effect like this is best left as a tbl/mission specs option.
You will also notice that there's a "Sound Environment" dialogue in .13 FRED where an option like this would be right at home.
-
I would still argue that an effect like this is best left as a tbl/mission specs option.
I agree... really all you need is a parameter that defines "speed of sound" in the current mission environment. Attaching it to the mission and defaulting it to "infinite" makes the most sense to me.
I think it would be a really cool effect, especially for a mod like Wings.
It's definitely a code change, but IMO a worthy feature to have.
-
That sounds convincing, thanks. :)
-
Considering how the only viable explanation of any sounds apart from collisions and your own ship's activity is that they're produced by speakers in the cabin to better utilize the pilot's aural sensory organs to increase situational awareness, I don't think this feature should be used in space missions.
However, I fully endorse adding this in the sound engine to be used for future atmospheric missions. If it is at all possible to code it in within human resources.
-
Atmospheric flight would definitely need this, but I wouldn't exclude its use in space missions for the sake of realism. At this point, I'd also say that speed of sound would boost situational awareness by adding the perception of distance to the perception of events.
Eyecandy and good gaming experience come before realism, anyway: this principle has been already applied to sounds in space, physics and many other things. Let's add something to the series. ;)
-
Atmospheric flight would definitely need this, but I wouldn't exclude its use in space missions for the sake of realism. At this point, I'd also say that speed of sound would boost situational awareness by adding the perception of distance to the perception of events.
Eyecandy and good gaming experience come before realism, anyway: this principle has been already applied to sounds in space, physics and many other things. Let's add something to the series. ;)
Mixing realism with Rule of Perception is just unnecessary. I can understand simulating doppler effect on the fly-by sounds because that just sounds cool and people expect it (thus, rule of perception).
However, as having sounds in space is far enough detached from reality, making the sounds have delays because sounds normally have delays would just be confusing logic. Having delays in the sounds like distant explosions wouldn't increase situational awareness or immersiveness because when you already breach the laws of physics to fulfill Role of Perception, then introducing this kind of pseudorealistic delays in space missions would just work to counter that because people would not expect them.
In other words you would just have bug reports claiming that a lot of sounds are out of synch and delayed.
I have to say, though, that a fully articulating sound physics engine including speed of sound, doppler effects and sound barrier (have fun with singularities though - phear the div by zero!) would be magnificent resource for any atmospheric missions.
-
Let me clarify: the effect, at least according to my original concept, would be fully optional. No one will be forced to have sounds in space as long as the script isn't used (or the effect is activated in FRED, since people are suggesting a code change rather than an actual script).
I like the flight sims that feature those delays: whenever I destroy a target, I feel the distance between me and the explosion... just like I do with thunders. Shouldn't that work in FreeSpace, too? IMHO, it will. The game features very big ships and feeling their dimensions whenever they explode is a real boost to immersion. :)
-
Doppler effect on sounds was recently tried and apparently it made everything sound awful.
-
I disagree, it wasn't awful--it just made certain sounds ****ty (such as the warpin-out sound)
-
Delay in sound arrival, I think, would actually be kind of cool. I think anyone who enjoys watching thunderstorms might agree.
-
Delay in sound arrival, I think, would actually be kind of cool. I think anyone who enjoys watching thunderstorms might agree.
At about 1:15 in this video (http://www.youtube.com/watch?v=RXvtR7Oy4Fk), this is about the effect I think of.
-
I disagree, it wasn't awful--it just made certain sounds ****ty (such as the warpin-out sound)
It wasn't awful, it just made things sound awful?
-
You nitpicky bastard. :rolleyes:
I was referring to how only some sounds were ****ty in the new sound code, and the rest sounded fine.
-
And I believe that was exactly the complaint behind the decision that it sounded awful.
-
Well, to say that "it sounded awful" would imply that the whole damn thing sounds awful, so if there's any way to fix the code so that certain sounds are not affected--that may be the golden fix for it.
Again, when you said "it sounds awful" it implied to me that you were referring to everything in-game (aside from music, since it's not affected by the new sound code) sounding awful.
-
Maybe we could have an option in the sounds.tbl or something that allows one to toggle Doppler effect on or off for certain sounds, so that Doppler effect on those that "sound awful" can be disabled.
-
At about 1:15 in this video (http://www.youtube.com/watch?v=RXvtR7Oy4Fk), this is about the effect I think of.
Yeah, that be kind of neat I think to have as an option.
-
My 2 cents. If your going to do it add an additional mission property for density so that sounds can arrive at variable speeds or not at all depending on if you are in Earth atmosphere, under water, Mars, etc.
-
The doppler effect is actually simulated to an extent within the current sound system (pre-overhaul). You can observe it when flying past other 3D sounds at high speed (most obviously with engine noises, where switching off flyby noises makes it seem more pronounced). Some of the early problems with the new sound code were that it applied pitch shifting effects to non-3D sounds like certain cockpit noises, and that the effect seemed to be far more wide-ranging than it was previously (maybe it was actually more "realistic", but I didn't think it sounded particularly good), but an approximation of the doppler has been there from the beginning. I've been crossing my fingers that the new code can get it back under control, cause it fixes a lot of other problems for me as well :D
-
Thanks for your posts, people. This thread's interesting.
I'd say to find a compromise in terms of feature availability: setting speed of sound as an option in FRED would somehow force people to deal with it, even those who don't want to. That's why I suggested a script in the first place, and also proposed a way to make it work. I would have created the script myself if only I had more experience with scripting. :sigh:
As for the doppler effect, that's also a nice thing to discuss. As far as I remember, I played at least one game that featured it, and I can ensure that many sounds become odd when closing. It's the price of realism.
How does the doppler effect work in FSO, by the way? Does it depend on angles?
Delay in sound arrival, I think, would actually be kind of cool. I think anyone who enjoys watching thunderstorms might agree.
You're great. :)
-
Thanks for your posts, people. This thread's interesting.
I'd say to find a compromise in terms of feature availability: setting speed of sound as an option in FRED would somehow force people to deal with it, even those who don't want to. That's why I suggested a script in the first place, and also proposed a way to make it work. I would have created the script myself if only I had more experience with scripting. :sigh:[/lightblue]
Why do I get the impression that you didn't actually understand what Sushi or I have said?
If anything like this gets implemented, it will be in the form of any number of other additions to FSO. That is to say, unless a modder or FREDer specifically turns this on, it will not be used.
You should also maybe (and this is just a hint) try out the Audio test builds posted on the Test builds forum. Those still have the Doppler effect in them. How it works? Ask the OpenAL spec. Which I think says that OAL Doppler works just like real-life Doppler, or as close to it as it can manage.
-
I would say most of the problems with doppler shift in the sound overhaul are related to
-some effects getting it backwards
-too low speed of sound values for what the players perceive (violates rule of perception), which results in way too much doppler shift.
To sound "good", the values need to be adjusted so that practically nothing in the game exceeds speed of sound in the fictious medium.
Also, there's a slight difference in doppler pitch in scenarios where the sound source moves and player stays still (relative to the fictious medium), or where sound source stays still in the medium and player moves through it, having relative velocity in the medium, and the most complex of all situations, where both move in the medium and have relative velocity between themselves.
The simplest way to simulate doppler pitch mathematically is to assume the player to stand still in the origo of the reference frame in which the sound moves; this essentially simulates how EM-radiation doppler shift works. It will also work with sound to certain extent, and might be sufficient to our purposes, but it IS somewhat different from reality which is a lot more complex, but I really really don't see fully realistic doppler shift system as a plausible solution. A slightly more advanced method would be to assume the game coordinates as a fixed medium for sound to propagate through and calculate all doppler effects based on that...
For example, theoretically if you have a fixed point source of sound and you fly away at Mach 2 you receive the waveform in reverse. And there are a lot of singularities to be expected if you allow even relative speeds of Mach 1+.
-
What about a speed of sound that is equal to 500ms-1? That should solve most, if not all of the problems caused by relative movements.
-
What about a speed of sound that is equal to 500ms-1? That should solve most, if not all of the problems caused by relative movements.
Only testing can possibly result in meaningful values, as this is something that has to be "played by the ear", if you wish.
Of course, doppler pitch and sound delay are two separate issues that are still to some extent interacting and complicating each other's implementation.
For example, if you utilize the sound delay and you end up with something like 1 second delay on a sound as it starts (if speed of sound is 500 m/s, distance would be 500 m) and the ships have a velocity of closure of 250 m/s (both ships afterburning at 125 m/s or so).
Fighter 1 produces a sound at t=0 s and the sound propagates towards Fighter 2's position at v = 500 m/s. At t=1s, the sound has reached the position where Fighter 2 was at t=0, but Fighter 2 has moved 125 metres on a line towards Fighter 2 and would have met the sound waves before the pre-calculated delay time has fulfilled.
And now you have a problem, computatively, that is. Do you want to make the delays acurate? Then you need to do some fairly fancy calculations with each sound produced by anything in range of the player, and in effect simulate the waveform spheres colliding with the player ship to calculate the delays accurately, and to determine the time to start the playback of the sound.
Then you would in addition to this have to calculate the velocity of objects that produced the sound and keep tracking that while the sound is produced, then apply that knowledge to how the player ship moves through the waveform...
Actually, the easiest brute force solution would be to detect the player ship's "collisions" with each sample of each waveform but you can see how that would be somewhat inappropriate and unfortunately expensive computationally. Basically you would have to do on-the-fly interpolation of each sample by changing the pitch of the sound based on how much the time between the samples differentiates from the original time between samples, and seeing how you would need to operate at around 44 kHz, that means 44100 samples per second per sound, and then you can have any number of sounds to simulate simultaneously...
:nervous:
-
:nervous: indeed.
I'd like to hear Wanderer's opinion on this, he may find a way to sort it out.
-
It seems to me that OpenAL would already have methods for this, as they have doppler shift, I'd think they would also have sound delay implemented. This shouldn't be something we have to calculate on our own. If OpenAL can't do it, then we'll just have to stick with Doppler shift alone as far as I care.
-
Bad idea. Well nice one but bad.
Of course that depends on the level at which the thing is done. Proper version would require 'collision tests' with expanding sound spheres and player/camera pos to get the distance and position for the sound.... Of course there are the shockwave 'collisions' already which (haven't checked that code yet) which might make the trick
Bad... As HT said.