Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Spoon on August 21, 2011, 09:12:01 am
-
I know, I know. I've complained about the sound code so many times now. And I will probably keep doing so until something changes.
Right now the new sound code will do some absolutely horrible things with sound. If you let a wing of 6 fighters warp in close to the player, you had better cover your ears. Because it will not sound like 6 fighters warping in. It will sound like 6 banshee's wailing as they crawl their way out of the deepest pits of the abyss. Battuta actually had to move a wing of fighters away from the player's starting point in WiH R2 exactly because of that. It will absolutely demolish your ears.
Same goes for turrets on salvo mode. As clearly evident here: http://youtu.be/41l9wwBrxrs?hd=1 during the first few seconds you will hear a turret firing 4 shots at once. It's a horrible clipped bgggghhhzz kinda noise. Not pretty at all.
Now I won't claim I know anything about the code or sound terms. But I would really love to see for one of you awesome super cool coders to either make it so that once a sound plays more then once on the same frame it will only play one time. Or that it will simply not be amplified the way it gets now and causes that bad clipping.
-
I know it's dated now but my SB Audigy with Creative Inspire speakers cant cope with it so please can the code be tweaked to fix this if possible.
-
Same goes for basically any nebula with lightning.
It sounds ridiculous, it's almost completely unplayable, you really only have one option; turn the sound off and play without it.
http://www.youtube.com/watch?v=DG9arxDnth4&lc=x4DnxsmXjbZxiwERXp81OIObn2e9dsii7V0kie8wW38&feature=inbox
T____________T
-
I actually don't remember what the original lightning sounds like anymore...
-
We'll get back to you once we get someone who knows this stuff.
-
Well since the new soundcode (1 year ago or more) i eared problem with beam as well.
-
We'll get back to you once we get someone who knows this stuff.
Despair :(
-
thats no good you most make an update
-
Instead of asking/demanding an update... why not request info on what skills are needed in said person for the sound code...
then start looking around the net for one.
Complaining about the problem when there's no one to fill the need won't make him poof into existence here and fix it any sooner.
-
I think MatthTheGeek was just joking around there.
-
Indeed he was :P
-
We'll get back to you once we get someone who knows this stuff.
Considering how big issues are presented by current sound code, it might be worth considering reverting taylor's soundcode back to what it used to be. You gain some, you lose some either way.
-
We'll get back to you once we get someone who knows this stuff.
Considering how big issues are presented by current sound code, it might be worth considering reverting taylor's soundcode back to what it used to be. You gain some, you lose some either way.
I'd be on board with this. It sucks (both from a lose-features and a painful-to-do point of view) but I've had nothing but grief from the sound code ever since it got changed. I've been kicking myself ever since for not paying more attention to Antipodes and not squawking about the problem before it was too late.
-
I put up some fair resistance to it's addition to trunk before it went in... :<
-
I put up some fair resistance to it's addition to trunk before it went in... :<
I remember that, actually.
-
I wouldn't mind reverting back to the old code.
Yes, on one hand its a shame. But considering the issues the new code has and the fact that nobody understands the code well enough to be able to support and fix these issues...
Also, I complained quite a while when it first went into the nightlies (mostly because how it utterly crapped up the sound on my old pc)
-
Could anyone kindly fill me in on what changed with the sound code (and/or what the supposed benefits were to be from switching to it over the old code?). Just curious.
-
People complained about the old sound code, and now they're complaining about the new one. Seriously guys. :p Let's see if we can do some intentional debugging instead of standing around complaining. Can someone go through the recent builds and find out when the particular problem appeared? Start in six month increments and narrow it down.
Also, try running with the -no_3d_sound command line and see if it fixes anything.
-
Could anyone kindly fill me in on what changed with the sound code (and/or what the supposed benefits were to be from switching to it over the old code?). Just curious.
Basically the internals of the sound code were rewritten to make better use of OpenALs capabilities rather than the engine having to baby feed the sound code. The three largest things, from *my* point of view, that were changed, was how the sound code detects sound cards and microphones, the really poor management of the sounds and (this is what is relevant to this discussion) enabling full 3d, multi-source audio.
The problem with the full 3d, multi-source audio is that, there is no cutoff on the volume and the number of sources in a certain point. The old sound code, implicitly had them because the old sound code would only attempt to play so many sounds a time (the "baby feeding") so it didn't overload the sound cards of the day (afaict, the old sound code is from retail except for being ported to openAL), whereas the new sound code sends every single sound to openAL and lets it figure out what to do. The end result is things like a wing warping in results in 4-6 warp sounds played at the same time, which being an already loud sound results in the extreme clipping everyone is complaining about.
Unfortunately, though I think I know what the problem is, I am not familiar enough with OpenAL to know how to fix it, and I haven't had time look into it.
People complained about the old sound code, and now they're complaining about the new one. Seriously guys. :p
Isn't that how it works... :P
-
People complained about the old sound code, and now they're complaining about the new one. Seriously guys. :p Let's see if we can do some intentional debugging instead of standing around complaining. Can someone go through the recent builds and find out when the particular problem appeared? Start in six month increments and narrow it down.
Also, try running with the -no_3d_sound command line and see if it fixes anything.
Durr? When did the problems occure? In the revision in which Taylor commited the sound code of course. :blah:
Thing is, we've got this sound code that apparantly nobody really understand due to the lack of openal knoweldge. It has these really bad issues that several people have raised complaints about. And its not being supported. This last bit should be enough indication imo to just pull it.
The new code could be great with tweaking and fixing, but since that is apparantly not going to happen anytime soon...
Edit: also no, -no_3d_sound does nothing to fix the clipping.
-
The problem with the full 3d, multi-source audio is that, there is no cutoff on the volume and the number of sources in a certain point. The old sound code, implicitly had them because the old sound code would only attempt to play so many sounds a time (the "baby feeding") so it didn't overload the sound cards of the day (afaict, the old sound code is from retail except for being ported to openAL), whereas the new sound code sends every single sound to openAL and lets it figure out what to do. The end result is things like a wing warping in results in 4-6 warp sounds played at the same time, which being an already loud sound results in the extreme clipping everyone is complaining about.
There is a volume cutoff, it's just a question of whether it works properly or not. [V] tried to get around some DS3D issues and I didn't take that code out since I didn't understand exactly what they were trying to do, how DS3D wasn't working the way they needed it too, or whether/how it's different for OpenAL.
There is also a cut off point for the number of sounds being played. The old code would, unless a certain flag was set, only allow a particular sound to be playing one at the time. The new code tries to be smarter about allowing things like that when there are plenty of sound sources free for use. Also the total number of sounds is only marginally higher than it used to be, 48 compared to 32 in the old code. And the difference there is because in the original DS code, effects and music used different sources of playback, whereas it all goes through the same OpenAL device and people were having voices and music not play due to sound effects taking up all of the available/allocated sound sources.
Unfortunately, though I think I know what the problem is, I am not familiar enough with OpenAL to know how to fix it, and I haven't had time look into it.
If you have an idea then spit it out and I'll help you figure out if that's the problem and how to go about fixing it.
Also it should be noted that in the test build thread for the new sound code that someone mentioned that the code broke with the go_faster commit. And before that point, if up to date drivers were used, along with the OpenAL Soft DLL, then the new sound code worked fine. So it's possible that there is an issue in there which isn't actually directly related to the sound code.
-
That was me.
But I've got a new pc now.
-
The problem with the full 3d, multi-source audio is that, there is no cutoff on the volume and the number of sources in a certain point. The old sound code, implicitly had them because the old sound code would only attempt to play so many sounds a time (the "baby feeding") so it didn't overload the sound cards of the day (afaict, the old sound code is from retail except for being ported to openAL), whereas the new sound code sends every single sound to openAL and lets it figure out what to do. The end result is things like a wing warping in results in 4-6 warp sounds played at the same time, which being an already loud sound results in the extreme clipping everyone is complaining about.
There is a volume cutoff, it's just a question of whether it works properly or not. [V] tried to get around some DS3D issues and I didn't take that code out since I didn't understand exactly what they were trying to do, how DS3D wasn't working the way they needed it too, or whether/how it's different for OpenAL.
Okay. I will have to take a closer look to find where it is done then.
There is also a cut off point for the number of sounds being played. The old code would, unless a certain flag was set, only allow a particular sound to be playing one at the time. The new code tries to be smarter about allowing things like that when there are plenty of sound sources free for use. Also the total number of sounds is only marginally higher than it used to be, 48 compared to 32 in the old code. And the difference there is because in the original DS code, effects and music used different sources of playback, whereas it all goes through the same OpenAL device and people were having voices and music not play due to sound effects taking up all of the available/allocated sound sources.
Okay, I recall seeing what you are referring to, but the issue is still one of, a sound possibly being played as multiple sources (ie. a wing warping in) at the same spot making what is already a loud sound (the warp and the lightning) that much louder.
Indeed, sorry if I was misleading in this regard, I haven't looked at the sound code in quite a while. Note, I am not trying to be evasive, I am trying to get some other code done up for the fiction viewer and command briefings that I promised to do long ago.
Unfortunately, though I think I know what the problem is, I am not familiar enough with OpenAL to know how to fix it, and I haven't had time look into it.
If you have an idea then spit it out and I'll help you figure out if that's the problem and how to go about fixing it.
I don't have anything that I haven't already stated with regards to what I outlined above about the multiple already loud sounds being played in close proximity, whereas, as far as I recall/could tell, the old code usually ended up only playing one of the loud sounds at a time.
Also it should be noted that in the test build thread for the new sound code that someone mentioned that the code broke with the go_faster commit. And before that point, if up to date drivers were used, along with the OpenAL Soft DLL, then the new sound code worked fine. So it's possible that there is an issue in there which isn't actually directly related to the sound code.
That was me.
But I've got a new pc now.
Do you still have the same problem with those builds? If the builds have been removed, I can rebuild them for you.
-
I noticed when playtesting a recent mission that it sounded as if warpin sounds made by a wing very far away were being played with a volume as if they occurred next to the player.
-
Do you still have the same problem with those builds? If the builds have been removed, I can rebuild them for you.
Not with my current pc I don't. And my old one got salvaged for parts so I can't go back and test it.
What the problem boiled down to was that with the new sound code, it sounded like everything took part in a cave. Then with soft openal installed it was resolved. But then when the go_faster code was commited the sound (and framerate) would become horribly distorted when too many sounds were playing.
-
I noticed when playtesting a recent mission that it sounded as if warpin sounds made by a wing very far away were being played with a volume as if they occurred next to the player.
Depending on the sound, that may very well be what happens. Not everything gets played in 3D, but all sounds occur in 3D space. So 2D sounds are played relative to the listener's (you) position in space using stereo panning. Meaning that 2D sounds are literally played right next to you.
So somebody probably needs to look and see if the warp sound is actually played in 3D or not. Just find where the sound is played in the code and see if it used snd_play() or snd_play_3d(). I know that the nebula lightning is played in 2D, so if the warp sound is as well then that narrows down where the problem might be.
-
Although the lightning issue is partially volume it is mostly frequency.
The nebula was never designed to play the lightning sound every time the lightning showed up, or if it was, it was done with the thought in mind that it wouldn't work.
Playing them allllll is never ever going to work, volume aside.
-
i dont know but i think i always played retail under eax because at the time i had a fairly decent sound blaster and thats what most games were using. but for the last several years ive mostly been satisfied with the onboard sound on whatever mobo i was using at the time. i also got away from the whatever.1 speakers everyone seems to like, last 5 years or so ive just been using full range stereo speaks and whatever analog stereo amp i could find at the time and i say the sound is much better.
anyway sounds like you need some real time gain correction code to level out the levels when you have a lot of sounds playing simultaneously. back in the old days it was one sound, one channel and the sound hardware would do the rest of the mixing for you. if a more modern sound setup tries to cram multiple sounds in the same channel by adding the samples (in the correct phase of course) then the result would be higher amplitude, not an actual mix. you would need to re-normalize the sample so that the amplitude remains constant. of course im not sure if the api works at that low of a level. id hate to roll back to direct sound over openal when the openal implementation can be fixed, given the right skill set.
-
anyway sounds like you need some real time gain correction code to level out the levels when you have a lot of sounds playing simultaneously. back in the old days it was one sound, one channel and the sound hardware would do the rest of the mixing for you. if a more modern sound setup tries to cram multiple sounds in the same channel by adding the samples (in the correct phase of course) then the result would be higher amplitude, not an actual mix. you would need to re-normalize the sample so that the amplitude remains constant. of course im not sure if the api works at that low of a level. id hate to roll back to direct sound over openal when the openal implementation can be fixed, given the right skill set.
Well that may be, though I think that OpenAL would already do something like that to help manage sounds.
Although the lightning issue is partially volume it is mostly frequency.
The nebula was never designed to play the lightning sound every time the lightning showed up, or if it was, it was done with the thought in mind that it wouldn't work.
Playing them allllll is never ever going to work, volume aside.
Yes. It seems this was/is an issue. The code that is in trunk does not enforce the built in concurrent playcount limits for any sound unless there is pressure on available playback channels. For example fighter sized ships are only supposed to play two warp-in sounds at a time. The nebula lightning there should only be two of both lightning variation.
So somebody probably needs to look and see if the warp sound is actually played in 3D or not. Just find where the sound is played in the code and see if it used snd_play() or snd_play_3d(). I know that the nebula lightning is played in 2D, so if the warp sound is as well then that narrows down where the problem might be.
I can confirm that nebula lightning is played in 2D, but the warpin sounds are defiantly played in 3d unless the 3d sound playback is disabled.
As I mentioned in my reply to QuantumDelta, I think I may have found the problem. It seems that the concurrent play count limits that are in place on a lot of the sounds (in particular the really loud sounds, aka warpin and lightning) were only being enforced once there was pressure on the available playback channels, which means that as I hypothesized previously about the limit on number of sounds at one time was actually true and in my limited testing (warp sounds in one mission) seems to help with the clipping and/or excessive volume.
So, here is a patch (below) and a release and a debug trunk based build below (remember that debug builds do not have lightning enabled) with the patch applied for everyones testing pleasure :P.
- always enforce the concurrent sound playcount.7z (http://www.box.net/shared/o1f4kolf16a0thylz0jy) (6.9MB; 7BD6D043ACFD3385C6B5A5FBEE79AEC432221B16)
Index: code/sound/ds.cpp
===================================================================
--- code/sound/ds.cpp (revision 7535)
+++ code/sound/ds.cpp (working copy)
@@ -1407,25 +1407,26 @@
}
}
+ // Make sure that we are not going to play more copies of this sound than we should be
+ if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
+ // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
+ if (lowest_instance_vol <= new_volume) {
+ ds_close_channel_fast(lowest_instance_vol_index);
+ first_free_channel = lowest_instance_vol_index;
+ }
+ }
+
if (first_free_channel < 0) {
- // If we've exceeded the limit, then maybe stop the duplicate if it is lower volume
- if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
- // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
- if (lowest_instance_vol <= new_volume) {
- ds_close_channel_fast(lowest_instance_vol_index);
- first_free_channel = lowest_instance_vol_index;
+ // still don't have a channel and
+ // there is no limit barrier to play the sound, so see if we've ran out of channels
+ // stop the lowest volume instance to play our sound if priority demands it
+ if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
+ // Check if the lowest volume playing is less than the volume of the requested sound.
+ // If so, then we are going to trash the lowest volume sound.
+ if ( Channels[lowest_vol_index].vol <= new_volume ) {
+ ds_close_channel_fast(lowest_vol_index);
+ first_free_channel = lowest_vol_index;
}
- } else {
- // there is no limit barrier to play the sound, so see if we've ran out of channels
- // stop the lowest volume instance to play our sound if priority demands it
- if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
- // Check if the lowest volume playing is less than the volume of the requested sound.
- // If so, then we are going to trash the lowest volume sound.
- if ( Channels[lowest_vol_index].vol <= new_volume ) {
- ds_close_channel_fast(lowest_vol_index);
- first_free_channel = lowest_vol_index;
- }
- }
}
}
-
Iss Mneur, you are a king! A King I say!
Using the build you provided, a warp in of 6 fighters no longer makes my ears start bleeding and a turret firing 4 shots at once now sound properly!
Get this **** into the trunk pronto!
-
How does this change affect nebula lightning?
-
Nebula lighting doesn't seem to have changed much in frequency, doesn't seem to clip or anything though.
I'm personally content with the current fixes to the warpin and turret sounds. I hardly even recall what the nebula lighting originally sounded like tbh. So I'm going to hand that issue over to QD cause he has a better clue on it.
-
This will, I hope, illustrate the differences;
http://www.youtube.com/watch?v=0yIz0O6jQp0
Sorry about the MVP use.
It is clear though that despite the slightly softer MVP effect, the game produced volume is much louder and much more frequent than with the retail sound code, pre-the new mvp (BP) lightning it could be really rather deafening.
Now it's not quite as bad but still something that could really do with proper re-tweaking.
As you can see however, the go_faster and Iss' re-tweak didn't effect the sound codes issues at all on this matter (warp ins seem fixed? you will probably notice however that one of the clips is completely devoid of warpin sound?).
Edit; for anyone really quick back to this reply, the video is about 10 minutes from finish of upload as of this post and will probably be another 5-10 minutes to fully encode. :P
-
Okay noticed just now that it's not working 100% perfectly. If you are at a certain range, the turret sounds will still clip like they used to. Its okay if you are close to the turret firing but after you put a certain amount of distance inbetween you and the turret it reverts to its old heathen ways.
-
That was very helpful QuantumDelta, it illustrates the issue quite clearly. I was able to replicate the issue. I don't know how you guys could stand the lightning (I never noticed because I normally end up playing with a debug build).
I think I may have been able to figure out what the problem is, I just don't know how to fix if it is actually the problem and/or how to fix it. What appears to be the problem with the lightning is that we are not allowing the sounds to play through, so we are always hearing the beginning of the rumble now, rather than having 40 playing at a time.
@Spoon, I have noticed that as well, but I am not really sure what the cause is, I need to look into it more. Do you have an example (with retail assets) that will do it?
-
We can't stand the lightning :P It was just brought up a bunch of times, and those threads all died from inactivity.
I'm very glad that a fix is being looked into.
-
With retail assets? No, as far as I know there is no ship with a 3 or 4 firing point turret in salvo mode.
I could record you a video of the issue though.
-
Wait, so it starts playing a bunch of lightning sounds, but instead of waiting to add another one until the earlier ones are done, it just starts shifting them off starting at the first one played?
-
Okay, this might be a silly question but... it'd be sillier not to ask it.
On GIMP, there are two different layer modes for doing almost the same thing: Addition and Screen.
They have a big practical difference, though - Addition simply adds the pixel values of the layer on top to the pixel values of the layer below, which can result to clipping if the values go over 255 for each channel.
Screen mode is more sophisticated, however. It never causes clipping, because it checks how much room there is available to the clipping point, then scales the top layer's pixel values to fill the available scale proportionally to the top layer's pixel values.
Example: I have two layers; bottom layer is a 75% grey (192,192,192 or #c0c0c0) and top layer is 50% grey (128,128,128 or #808080).
Additive blending mode would count the pixel values directly together and end up with clipped white at 192+128=320>255.
Screen mode first determines how much available values there are before clipping occurs:
255-192 = 63
Then it determines how much it wants to increase the value perceptually. The 50% grey would mean a 50% increase of available values. In this case,
63 * 128/255 = 31.6235294 = ~32
...so the final pixel value is
192 + 32 = 224
and the colour ends up as (224,224,224 or #e0e0e0).
Mathematically, it goes as follows:
RGB(out) = RGB(bottom) + ( [ RGB(white) - RGB(bottom) ] * [ RGB(top) / RGB(white) ] )
Now, for image editing, every RGB variable consists of three numerals for RGB, four with RGBA (but that works a bit differently as the alpha channel of top layer is a multiplier for the RGB values in 0,1 range...) and the range for each channel is 0,255.
For audio, we have only one value (sample) but lots of them coming in at high rate of speed (typically 44100 in one second minimum) and the size of individual sample is usually 16bit, 24bit or 32bit integer. Most commonly the sound data is in 44k16bit format; however while processing the sound, they can either be converted to higher sample size or kept at the same 16 bit (at slight sacrifice of rounding errors).
Regardless, with additive mixing of two samples, the sample values are just added together and if they go over the clipping threshold you end up with clipping sound.
With a "screen" type mixing of samples, you will never get clipping; the volume will just asymptotically approach 0 dB. Of course sound is a bit different as waveform contains both positive and negative values, while image data is limited to positive values; however the equation can probably be adjusted to take negative values into account and prevent clipping for negative values as well.
Now, the questions:
Is there some flaw in my thinking as to why this wouldn't work? If yes, what is it?
If this should theoretically work, then:
Does OpenAL support this type of mixing that never clips? If it is, how to use it?
If this is not possible, then I have to ask... why not? Is it too resource-intensive? It wouldn't seem so, as it's all rather simple maths - you just need to do it pretty fast (at least 44100 times per second multiplied by the amount of sounds used).
-
i think the problem with this is the sound api, which should in theory handle all this low level stuff for you and only gives you control of higher level structures, sounds, channels, etc. of course i never used openal before for anything i ever wrote, nor would i. i would probably just use the sound features of sdl, since im somewhat familiar with it.
-
So I have had a chance to think about it.
As I see it, we have three options that may or may not work:
- Change the way that we play the sounds so that we will only play two of each type and let them finish before we start again. My concern with this is it will make the thunder less "interesting" because it always plays through.
- Change the nebula lightning so that it doesn't play thunder for every single strike. As it is right now, FSO attempts to play one of the thunder sounds for every single lightning bolt that is in range (about 1.5km), this is similar to what QD mentioned previously.
- Try putting the the nebula sounds into 3D to see if we can make them sound better and/or reduce the annoyance of the sounds always being played directly behind your head.
TBH, I will probably try all three variations and see what is liked better.
Wait, so it starts playing a bunch of lightning sounds, but instead of waiting to add another one until the earlier ones are done, it just starts shifting them off starting at the first one played?
Yep.
@Herra Tohtori: I can't see why that wouldn't work, but I have to show my inexperience with OpenAL in this, I don't know if it is able to (though I can't see why not, you can't be the first person to have thought of this). However, with in the nebula lighting in particular, being able to play 20 lighting sounds (of 48 available) channels seems like a waste to me, I can think of better sounds to be playing in those channels.
-
Can you change the code to only play lightning that is within about 250m-500m of the player? That way the frequency of noise is down, but the closest, (most intense) lightning will always be played.
An added slight glare affect for lightning within that same range might help keep lightning interesting. <-- It's ok if that's too complicated, just adding ideas.
-
I do know that the Nebula Lightning is not currently tabled (in retail) as being a 3D sound, so we'd have to force that if we expect it to work on Retail data.
Course, we'll probably also have to check if a mod makes it a 3D sound and use that setting vs forcing it even if set. (This probably doesn't make much sense, I'll see if I can explain it after coffee)
-
How hard would it be to make it a 3D sound and write a table? Or am I completely missing the point?
-
@Herra Tohtori: I can't see why that wouldn't work, but I have to show my inexperience with OpenAL in this, I don't know if it is able to (though I can't see why not, you can't be the first person to have thought of this). However, with in the nebula lighting in particular, being able to play 20 lighting sounds (of 48 available) channels seems like a waste to me, I can think of better sounds to be playing in those channels.
you should always try to make use of every sound channel there is. if sounds have a priority you could use up more sound channels for environmental effects when theres not much action going on, then have them use up fewer channels when there is combat. if priority worked like this:
1 self sounds (ship, hud, firing of player weapons etc)
2 combat sounds (beams, guns, missiles, other ships, explosions, etc)
3 environmental sounds (lightning)
priority 1 sounds always play and get first dibs on available sound channels
priority 2 and 3 sounds get 2nd and 3rd dibs on remaining sound channels.
sounds should also be further prioritized by distance from the player, play volume, and age in queue. drop distant and/or quiet sounds of priority 2 or greater. some sounds also need not be played on time, such as low priority sounds or sounds behind you that have no real effect on what your doing (things like shockwave explosions that hit you or that bogey on your six and its weapons would probably be excluded). so sounds are queued up as they are requested, and when this happens sounds are assigned a timestamp for its creation and also when it expires. expired sounds are removed from the queue. but an old sound that hasnt expired yet is a good candidate for de-prioritization.
of course before that happens you cull out a bunch of sounds if you have multiple instances of a single sound playing in close proximity to each other at close to the same time (probably determined using some 4d vector math), then the time and position should be averaged and a single sound played from that location and time (this would require some foreknowledge of what was gonna happen, as if the sounds were sitting in the queue for a couple of frames). this would improve the sounds of simultaneous lightning strikes and ship warpins, and assuming there wont be any clipping the sound could be played at a slightly higher volume (if your typical sound plays at 75% then you could amp the loud sound an additional 25% before clipping occurs). predictable events can even do this before hand making the sound queue smaller.
-
That's a great idea. This should get rid of problems with rapid-fire weapons causing sound problems, as well as improve overall immersion in a sound-rich environment (think a battle with a lot of rapid-fire guns).
-
rapid fire weapons should just run a sound loop that lasts for several shots. youd have to have a real ocd to figure out that you fired fewer shots than shot sounds you heard. if the cables are still too thick you could probibly play part of a loop to represent the loose shots so it doesnt make you pluck your eyes out and eat them. if a loop represents 5 shots and only 3 shots are fired, play 60% of the sound. i think this is what stream was meant to do but either wasnt implemented or didnt work and was made to do nothing so that it didnt break a bunch of tables before the game was released. the fact that the flag mostly appears on rapid fire weapons really makes me think thats what happened.
-
How hard would it be to make it a 3D sound and write a table? Or am I completely missing the point?
how does that help anybody running in "Retail" mode?
-
How hard would it be to make it a 3D sound and write a table? Or am I completely missing the point?
how does that help anybody running in "Retail" mode?
If you are running retail, you don't need a build with the sound code. If you are playing with mediavp's this is a none issue.
Or am I missing something about this "Retail mode" ?
-
"Retail" mode means: FSO exec, sans MediaVPs. Note the quotes around Retail indicating that I don't mean Retail.
-
Pardon my ignorance, but are the nebula lightning sounds internally (from the engine's PoV) considered objects (models) generating sound or just an environmental thing that has X% of playing every Y seconds? I'm guessing the former based on Zacam's comments, but I just want to know for sure.
-
How hard would it be to make it a 3D sound and write a table? Or am I completely missing the point?
how does that help anybody running in "Retail" mode?
Put the table as a vp in FS2 Root\tables or wherever they go.
-
How hard would it be to make it a 3D sound and write a table? Or am I completely missing the point?
how does that help anybody running in "Retail" mode?
Put the table as a vp in FS2 Root\tables or wherever they go.
That would not work since the SCP doesn't do VPs, only the FSU does VPs. In short, it would go against what the SCP is supposed to do.
-
Not if the table had a conditional to make it only be read by 3.6.xx like the music table for FSPort does. Then it wouldn't be read unless you were using FSO exes.
-
Not if the table had a conditional to make it only be read by 3.6.xx like the music table for FSPort does. Then it wouldn't be read unless you were using FSO exes.
That's not the point. Both FSPort and FSU are content projects, VPs are their purpose. The SCP does code only, so if anyone were to do VPs it would have to be the FSU. However it would then be a moot point since Zacam's entire argument was what to do about people that don't use the MediaVPs that the FSU provides.
-
I thought that at this point, FSO required at minimum MV_Root.vp to operate? And besides, .vps are just containers for the files. If you wanted, you could make the table hard-coded into the FSO .exes and just have it able to be overridden by an actual .vp or .tbl in the FS2 file structure. Right?
-
What? No. I am quite sure that the exe still runs the retail data just fine. If it doesn't, that would be a serious regression.
-
Several mods require a bare minimum of FSU compatibility provided by MV_Root.vp; many more mods require full MediaVP's. At least, as far as I know. I typically use mediavps anyway so I wouldn't know what mods can be run without...
The retail data still should work quite fine with FS2_Open engine.
-
Someone please give this patch a try and see if it does anything for the volume problems.
It seems quite apparent that the volume for all sound has increased at some point. The actual volume for individual sounds appears to be the same, so I don't really have an explanation for the difference. This patch just drops the gain for the master volume in OpenAL to more approximately match what the pre-new-sound code had (according to my ears in a quick test).
This does nothing for nebula lightning frequency though. A better fix for that is simply editing the neblightning code to avoid playing sound too frequently, as opposed to re-imposing the hard playback count limits in the sound code directly (which was necessary at the time, but is a bug at this point). There is really no reason to make nebula lightning 3D, as that isn't going to fix anything. And it already avoids sound playback for any bolt over 400m away. The code just needs to be modified to be smart about not playing too much sound in busy storms, which is something that it used to rely on the hardware limitations of the sound code to sort out.
[attachment deleted by ninja]
-
I'd test but I'd like a file I can actually do anything with.
-
Here are builds with the change mentioned above: http://blueplanet.fsmods.net/E/stuff/soundtest.7z
-
That seems to be a step backwards. There's more noticable clipping on that latest build compared to the one Iss Mneur's posted (though the clipping itself is less ear shredding) and at times its not playing sounds from turrets close (and in the viewing cone) to you at all.
-
http://www.youtube.com/watch?v=zqtOhEgE2oA
.....Hopefully, if not I'll encode the two together tomorrow anyway
-
Okay, another build to try.
This is a rollup of a few different changes so that that we can come up with some appropriate values and/or defaults. The changes included are:
- My fix from previously (http://www.hard-light.net/forums/index.php?topic=77889.msg1542937#msg1542937) disabled by default. Enable with cmdline flag -alwaysenforce.
- Allows dynamic adjustment of the change that Taylor posted (http://www.hard-light.net/forums/index.php?topic=77889.msg1543729#msg1543729). By default it is also off. Control this feature with -listenergain <value>. -1 disables. Useful range is 0.0 (effectively turns off sound) to 1.0 (presumably the same as -1). Taylor's patch sets this to 0.65.
- Allows control of the percentage of new lightning flashes that get turned into bangs (aka thunder sound plays). Controlled with -percent_flashtobang <value>. Default is 100. I find 25 is too boring, 75 is still too much sound.
Thoughts? Please post the settings of the above three flags and whether you are using the OpenALSoft.dll so that we can use the numbers to come up with good defaults for retail to use.
- More sound code fun.7z (http://www.box.net/shared/tqpqk9s0qugczcyatpbv) (1.5MB; SHA-1: 7C2BD7D90BB8488A4B32EB093425E81E114C393A)
Index: code/cmdline/cmdline.cpp
===================================================================
--- code/cmdline/cmdline.cpp (revision 7567)
+++ code/cmdline/cmdline.cpp (working copy)
@@ -437,8 +437,16 @@
cmdline_parm output_sexp_arg("-output_sexps", NULL); //WMC - outputs all SEXPs to sexps.html
cmdline_parm output_scripting_arg("-output_scripting", NULL); //WMC
+float Cmdline_percentflashtobang = 100.0f;
+float Cmdline_listenergain = -1;
+int Cmdline_enforce_concurrent_sound_count = 0;
+cmdline_parm percent_flashtobang_arg("-percent_flashtobang", NULL);
+cmdline_parm listenergain_arg("-listenergain", NULL);
+cmdline_parm always_enforce_concurrent_sound("-alwaysenforce", NULL);
+
+
#ifndef NDEBUG
// NOTE: this assumes that os_init() has already been called but isn't a fatal error if it hasn't
void cmdline_debug_print_cmdline()
@@ -1450,6 +1458,21 @@
Cmdline_bloom_intensity = bloom_intensity_arg.get_int();
}
+ if ( listenergain_arg.found() )
+ {
+ Cmdline_listenergain = listenergain_arg.get_float();
+ }
+
+ if ( percent_flashtobang_arg.found() )
+ {
+ Cmdline_percentflashtobang = percent_flashtobang_arg.get_float();
+ }
+
+ if ( always_enforce_concurrent_sound.found() )
+ {
+ Cmdline_enforce_concurrent_sound_count = 1;
+ }
+
return true;
}
Index: code/cmdline/cmdline.h
===================================================================
--- code/cmdline/cmdline.h (revision 7567)
+++ code/cmdline/cmdline.h (working copy)
@@ -145,7 +145,10 @@
extern int Cmdline_no_grab;
#endif
+// Temp, only for evaluating new defaults
+extern float Cmdline_listenergain;
+extern float Cmdline_percentflashtobang;
+extern int Cmdline_enforce_concurrent_sound_count;
-
//extern char FreeSpace_Directory[]; // allievating a cfilesystem problem caused by fred -- Kazan
#endif
Index: code/nebula/neblightning.cpp
===================================================================
--- code/nebula/neblightning.cpp (revision 7567)
+++ code/nebula/neblightning.cpp (working copy)
@@ -21,10 +21,8 @@
#include "weapon/emp.h"
#include "network/multi.h"
#include "network/multimsgs.h"
+#include "cmdline/cmdline.h"
-
-extern int Cmdline_nohtl;
-
// ------------------------------------------------------------------------------------------------------
// NEBULA LIGHTNING DEFINES/VARS
//
@@ -439,24 +437,27 @@
// do some special stuff on the very first strike of the bolt
if(b->strikes_left == bi->num_strikes){
- // play a sound
- float bang;
- if(Nebl_bang < 40.0f){
- bang = 1.0f;
- } else if(Nebl_bang > 400.0f){
- bang = 0.0f;
- } else {
- bang = 1.0f - (Nebl_bang / 400.0f);
- }
- if(frand_range(0.0f, 1.0f) < 0.5f){
- snd_play(&Snds[SND_LIGHTNING_2], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
- } else {
- snd_play(&Snds[SND_LIGHTNING_1], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
- }
+ // play a sound
+ if (frand_range(0.0f, 100.0f) < Cmdline_percentflashtobang)
+ {
+ float bang;
+ if(Nebl_bang < 40.0f){
+ bang = 1.0f;
+ } else if(Nebl_bang > 400.0f){
+ bang = 0.0f;
+ } else {
+ bang = 1.0f - (Nebl_bang / 400.0f);
+ }
+ if(frand_range(0.0f, 1.0f) < 0.5f){
+ snd_play(&Snds[SND_LIGHTNING_2], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
+ } else {
+ snd_play(&Snds[SND_LIGHTNING_1], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
+ }
- // apply em pulse
- if(bi->emp_intensity > 0.0f){
- emp_apply(&b->midpoint, 0.0f, vm_vec_dist(&b->start, &b->strike), bi->emp_intensity, bi->emp_time);
+ // apply em pulse
+ if(bi->emp_intensity > 0.0f){
+ emp_apply(&b->midpoint, 0.0f, vm_vec_dist(&b->start, &b->strike), bi->emp_intensity, bi->emp_time);
+ }
}
}
}
Index: code/sound/ds.cpp
===================================================================
--- code/sound/ds.cpp (revision 7567)
+++ code/sound/ds.cpp (working copy)
@@ -18,8 +18,8 @@
#include "sound/acm.h"
#include "osapi/osapi.h"
#include "sound/dscap.h"
+#include "cmdline/cmdline.h"
-
typedef struct sound_buffer
{
ALuint buf_id; // OpenAL buffer id
@@ -1129,6 +1129,10 @@
// this is needed for 2D pan
OpenAL_ErrorPrint( alListener3f(AL_POSITION, 0.0, 0.0, 0.0) );
OpenAL_ErrorPrint( alListenerfv(AL_ORIENTATION, list_orien) );
+ if (Cmdline_listenergain > 0)
+ {
+ OpenAL_ErrorPrint( alListenerf(AL_GAIN, Cmdline_listenergain) );
+ }
// disable doppler (FIXME)
OpenAL_ErrorPrint( alDopplerFactor(0.0f) );
@@ -1407,24 +1411,33 @@
}
}
+ // Make sure that we are not going to play more copies of this sound than we should be
+ if ( Cmdline_enforce_concurrent_sound_count && (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
+ // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
+ if (lowest_instance_vol <= new_volume) {
+ ds_close_channel_fast(lowest_instance_vol_index);
+ first_free_channel = lowest_instance_vol_index;
+ }
+ }
+
if (first_free_channel < 0) {
- // If we've exceeded the limit, then maybe stop the duplicate if it is lower volume
+ // Make sure that we are not going to play more copies of this sound than we should be
if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
// If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
if (lowest_instance_vol <= new_volume) {
ds_close_channel_fast(lowest_instance_vol_index);
first_free_channel = lowest_instance_vol_index;
}
- } else {
- // there is no limit barrier to play the sound, so see if we've ran out of channels
- // stop the lowest volume instance to play our sound if priority demands it
- if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
- // Check if the lowest volume playing is less than the volume of the requested sound.
- // If so, then we are going to trash the lowest volume sound.
- if ( Channels[lowest_vol_index].vol <= new_volume ) {
- ds_close_channel_fast(lowest_vol_index);
- first_free_channel = lowest_vol_index;
- }
+ }
+ // still don't have a channel and
+ // there is no limit barrier to play the sound, so see if we've ran out of channels
+ // stop the lowest volume instance to play our sound if priority demands it
+ if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
+ // Check if the lowest volume playing is less than the volume of the requested sound.
+ // If so, then we are going to trash the lowest volume sound.
+ if ( Channels[lowest_vol_index].vol <= new_volume ) {
+ ds_close_channel_fast(lowest_vol_index);
+ first_free_channel = lowest_vol_index;
}
}
}
-
-alwaysenforce enabled while not perfect does give the best result, fixing sound from turrets&warpins 85% of the time. -listenergain between 0.8 - 0.9 slightly reduces the amount of clipping when it does happen, without making it sound like I need to turn up the volume of my speakers because the general sound volume sounds so soft. Imo if -alwaysenforce would work at every distance properly there would be no need for -listenergain at all.
-percent_flashtobang at 60 seems to give a pretty good nebula result.
not using openalsoft
-
excuse me guys,but do you hear the capship warping effect?
and the capship explosion? the sound should be the Atomic.wav but what i only hear is the clusterboom sound.
i noticed that working on Diaspora... i think is not only our issue,but i think is a bug in the code.
Plus, the Capship engine not work...if you pass near a ship like the Colossus,you hear nothing IIRC.
thanks in advance for your help
-
excuse me guys,but do you hear the capship warping effect?
and the capship explosion? the sound should be the Atomic.wav but what i only hear is the clusterboom sound.
i noticed that working on Diaspora... i think is not only our issue,but i think is a bug in the code.
Plus, the Capship engine not work...if you pass near a ship like the Colossus,you hear nothing IIRC.
thanks in advance for your help
BUMP
ehm...i quoted myself...
thanks again :)
-
Guys, Seriously.
Stop the irrelevant talk about speaker set ups and audiocards and do something with this:
Okay, another build to try.
This is a rollup of a few different changes so that that we can come up with some appropriate values and/or defaults. The changes included are:
- My fix from previously (http://www.hard-light.net/forums/index.php?topic=77889.msg1542937#msg1542937) disabled by default. Enable with cmdline flag -alwaysenforce.
- Allows dynamic adjustment of the change that Taylor posted (http://www.hard-light.net/forums/index.php?topic=77889.msg1543729#msg1543729). By default it is also off. Control this feature with -listenergain <value>. -1 disables. Useful range is 0.0 (effectively turns off sound) to 1.0 (presumably the same as -1). Taylor's patch sets this to 0.65.
- Allows control of the percentage of new lightning flashes that get turned into bangs (aka thunder sound plays). Controlled with -percent_flashtobang <value>. Default is 100. I find 25 is too boring, 75 is still too much sound.
Thoughts? Please post the settings of the above three flags and whether you are using the OpenALSoft.dll so that we can use the numbers to come up with good defaults for retail to use.
- More sound code fun.7z (http://www.box.net/shared/tqpqk9s0qugczcyatpbv) (1.5MB; SHA-1: 7C2BD7D90BB8488A4B32EB093425E81E114C393A)
Index: code/cmdline/cmdline.cpp
===================================================================
--- code/cmdline/cmdline.cpp (revision 7567)
+++ code/cmdline/cmdline.cpp (working copy)
@@ -437,8 +437,16 @@
cmdline_parm output_sexp_arg("-output_sexps", NULL); //WMC - outputs all SEXPs to sexps.html
cmdline_parm output_scripting_arg("-output_scripting", NULL); //WMC
+float Cmdline_percentflashtobang = 100.0f;
+float Cmdline_listenergain = -1;
+int Cmdline_enforce_concurrent_sound_count = 0;
+cmdline_parm percent_flashtobang_arg("-percent_flashtobang", NULL);
+cmdline_parm listenergain_arg("-listenergain", NULL);
+cmdline_parm always_enforce_concurrent_sound("-alwaysenforce", NULL);
+
+
#ifndef NDEBUG
// NOTE: this assumes that os_init() has already been called but isn't a fatal error if it hasn't
void cmdline_debug_print_cmdline()
@@ -1450,6 +1458,21 @@
Cmdline_bloom_intensity = bloom_intensity_arg.get_int();
}
+ if ( listenergain_arg.found() )
+ {
+ Cmdline_listenergain = listenergain_arg.get_float();
+ }
+
+ if ( percent_flashtobang_arg.found() )
+ {
+ Cmdline_percentflashtobang = percent_flashtobang_arg.get_float();
+ }
+
+ if ( always_enforce_concurrent_sound.found() )
+ {
+ Cmdline_enforce_concurrent_sound_count = 1;
+ }
+
return true;
}
Index: code/cmdline/cmdline.h
===================================================================
--- code/cmdline/cmdline.h (revision 7567)
+++ code/cmdline/cmdline.h (working copy)
@@ -145,7 +145,10 @@
extern int Cmdline_no_grab;
#endif
+// Temp, only for evaluating new defaults
+extern float Cmdline_listenergain;
+extern float Cmdline_percentflashtobang;
+extern int Cmdline_enforce_concurrent_sound_count;
-
//extern char FreeSpace_Directory[]; // allievating a cfilesystem problem caused by fred -- Kazan
#endif
Index: code/nebula/neblightning.cpp
===================================================================
--- code/nebula/neblightning.cpp (revision 7567)
+++ code/nebula/neblightning.cpp (working copy)
@@ -21,10 +21,8 @@
#include "weapon/emp.h"
#include "network/multi.h"
#include "network/multimsgs.h"
+#include "cmdline/cmdline.h"
-
-extern int Cmdline_nohtl;
-
// ------------------------------------------------------------------------------------------------------
// NEBULA LIGHTNING DEFINES/VARS
//
@@ -439,24 +437,27 @@
// do some special stuff on the very first strike of the bolt
if(b->strikes_left == bi->num_strikes){
- // play a sound
- float bang;
- if(Nebl_bang < 40.0f){
- bang = 1.0f;
- } else if(Nebl_bang > 400.0f){
- bang = 0.0f;
- } else {
- bang = 1.0f - (Nebl_bang / 400.0f);
- }
- if(frand_range(0.0f, 1.0f) < 0.5f){
- snd_play(&Snds[SND_LIGHTNING_2], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
- } else {
- snd_play(&Snds[SND_LIGHTNING_1], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
- }
+ // play a sound
+ if (frand_range(0.0f, 100.0f) < Cmdline_percentflashtobang)
+ {
+ float bang;
+ if(Nebl_bang < 40.0f){
+ bang = 1.0f;
+ } else if(Nebl_bang > 400.0f){
+ bang = 0.0f;
+ } else {
+ bang = 1.0f - (Nebl_bang / 400.0f);
+ }
+ if(frand_range(0.0f, 1.0f) < 0.5f){
+ snd_play(&Snds[SND_LIGHTNING_2], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
+ } else {
+ snd_play(&Snds[SND_LIGHTNING_1], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
+ }
- // apply em pulse
- if(bi->emp_intensity > 0.0f){
- emp_apply(&b->midpoint, 0.0f, vm_vec_dist(&b->start, &b->strike), bi->emp_intensity, bi->emp_time);
+ // apply em pulse
+ if(bi->emp_intensity > 0.0f){
+ emp_apply(&b->midpoint, 0.0f, vm_vec_dist(&b->start, &b->strike), bi->emp_intensity, bi->emp_time);
+ }
}
}
}
Index: code/sound/ds.cpp
===================================================================
--- code/sound/ds.cpp (revision 7567)
+++ code/sound/ds.cpp (working copy)
@@ -18,8 +18,8 @@
#include "sound/acm.h"
#include "osapi/osapi.h"
#include "sound/dscap.h"
+#include "cmdline/cmdline.h"
-
typedef struct sound_buffer
{
ALuint buf_id; // OpenAL buffer id
@@ -1129,6 +1129,10 @@
// this is needed for 2D pan
OpenAL_ErrorPrint( alListener3f(AL_POSITION, 0.0, 0.0, 0.0) );
OpenAL_ErrorPrint( alListenerfv(AL_ORIENTATION, list_orien) );
+ if (Cmdline_listenergain > 0)
+ {
+ OpenAL_ErrorPrint( alListenerf(AL_GAIN, Cmdline_listenergain) );
+ }
// disable doppler (FIXME)
OpenAL_ErrorPrint( alDopplerFactor(0.0f) );
@@ -1407,24 +1411,33 @@
}
}
+ // Make sure that we are not going to play more copies of this sound than we should be
+ if ( Cmdline_enforce_concurrent_sound_count && (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
+ // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
+ if (lowest_instance_vol <= new_volume) {
+ ds_close_channel_fast(lowest_instance_vol_index);
+ first_free_channel = lowest_instance_vol_index;
+ }
+ }
+
if (first_free_channel < 0) {
- // If we've exceeded the limit, then maybe stop the duplicate if it is lower volume
+ // Make sure that we are not going to play more copies of this sound than we should be
if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
// If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
if (lowest_instance_vol <= new_volume) {
ds_close_channel_fast(lowest_instance_vol_index);
first_free_channel = lowest_instance_vol_index;
}
- } else {
- // there is no limit barrier to play the sound, so see if we've ran out of channels
- // stop the lowest volume instance to play our sound if priority demands it
- if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
- // Check if the lowest volume playing is less than the volume of the requested sound.
- // If so, then we are going to trash the lowest volume sound.
- if ( Channels[lowest_vol_index].vol <= new_volume ) {
- ds_close_channel_fast(lowest_vol_index);
- first_free_channel = lowest_vol_index;
- }
+ }
+ // still don't have a channel and
+ // there is no limit barrier to play the sound, so see if we've ran out of channels
+ // stop the lowest volume instance to play our sound if priority demands it
+ if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
+ // Check if the lowest volume playing is less than the volume of the requested sound.
+ // If so, then we are going to trash the lowest volume sound.
+ if ( Channels[lowest_vol_index].vol <= new_volume ) {
+ ds_close_channel_fast(lowest_vol_index);
+ first_free_channel = lowest_vol_index;
}
}
}
Trying to fix the sound code here, useful feedback has been requested.
-
excuse me guys,but do you hear the capship warping effect?
and the capship explosion? the sound should be the Atomic.wav but what i only hear is the clusterboom sound.
i noticed that working on Diaspora... i think is not only our issue,but i think is a bug in the code.
Plus, the Capship engine not work...if you pass near a ship like the Colossus,you hear nothing IIRC.
thanks in advance for your help
BUMP
ehm...i quoted myself...
thanks again :)
Your post that you quoted wasn't even up for 8 hours before you bumped it, 24-48 hours is a more realistic timeline. If you want instant answers, use FS modding or #hard-light (assuming they have the answer for you), if you want researched answers, give the coders some time to research it.
Since you posted in this thread, I assume that is because the build that I posted breaks these sounds for you? I have not changed anything that should affect the playback of these sounds, so if this build is breaking it, go to the the nightly build forum (http://www.hard-light.net/forums/index.php?board=173.0) and try the builds there to locate where we broke the sounds in question.
For the record, I tested this last night, the correct warp, explosion, and engine sounds play just fine for me with retail assets in the trunk build and the build that I posted here. More than likely the problem is a mod data issue and the ship that is not playing the explosion or warp sound is missing the "capital" ship flag. I didn't get a chance to check on the specific requirements for engine sounds.
Trying to fix the sound code here, useful feedback has been requested.
Yes please.
With respect to the speakers and audio cards, find the settings (with retail assets) that you like the best with whatever you play the game with. I am going to make whatever the consensus is the defaults for the engine. The cmdline flags are not staying.
-
The listener gain thing is pointless as a fix. I thought that it would help out, and if you don't look at it all too carefully then it does, but after going through the code (FSO and OpenAL) it is just a stupid thing.
I have found several bugs though, most specifically for warps and beams, where they are supposed be played as 3D sounds but get converted to being partially 2D and just kind of breaking how it's supposed to work/sound. I've fixed that, but it still needs testing.
I also tested putting a timestamp on the nebula lightning so that it won't play a sound except in 750 ms intervals. Doing this appears to best mimic the most of what retail tended to play. But the main thing is that it got rid of the clipping 100% in my tests. 500ms clips a bit, 1000ms is too long of a time between sounds. As a fix it appears to be the only thing that has worked perfectly for me, but it could probably use further tweaking to be even better.
Additionally I am working on some code to step down the gain of multiple of the same sound. There are a few ways to go about this though and I haven't quite figured out how best to do it yet. But the idea is that it should (hopefully) squash the clipping issue while still allowing for the full and rich sound environment provided by the new sound code.
Anyway, just an update on what I've found.
-
Guys, Seriously.
Stop the irrelevant talk about speaker set ups and audiocards and do something with this:
Okay, another build to try.
This is a rollup of a few different changes so that that we can come up with some appropriate values and/or defaults. The changes included are:
- My fix from previously (http://www.hard-light.net/forums/index.php?topic=77889.msg1542937#msg1542937) disabled by default. Enable with cmdline flag -alwaysenforce.
- Allows dynamic adjustment of the change that Taylor posted (http://www.hard-light.net/forums/index.php?topic=77889.msg1543729#msg1543729). By default it is also off. Control this feature with -listenergain <value>. -1 disables. Useful range is 0.0 (effectively turns off sound) to 1.0 (presumably the same as -1). Taylor's patch sets this to 0.65.
- Allows control of the percentage of new lightning flashes that get turned into bangs (aka thunder sound plays). Controlled with -percent_flashtobang <value>. Default is 100. I find 25 is too boring, 75 is still too much sound.
Thoughts? Please post the settings of the above three flags and whether you are using the OpenALSoft.dll so that we can use the numbers to come up with good defaults for retail to use.
- More sound code fun.7z (http://www.box.net/shared/tqpqk9s0qugczcyatpbv) (1.5MB; SHA-1: 7C2BD7D90BB8488A4B32EB093425E81E114C393A)
Index: code/cmdline/cmdline.cpp
===================================================================
--- code/cmdline/cmdline.cpp (revision 7567)
+++ code/cmdline/cmdline.cpp (working copy)
@@ -437,8 +437,16 @@
cmdline_parm output_sexp_arg("-output_sexps", NULL); //WMC - outputs all SEXPs to sexps.html
cmdline_parm output_scripting_arg("-output_scripting", NULL); //WMC
+float Cmdline_percentflashtobang = 100.0f;
+float Cmdline_listenergain = -1;
+int Cmdline_enforce_concurrent_sound_count = 0;
+cmdline_parm percent_flashtobang_arg("-percent_flashtobang", NULL);
+cmdline_parm listenergain_arg("-listenergain", NULL);
+cmdline_parm always_enforce_concurrent_sound("-alwaysenforce", NULL);
+
+
#ifndef NDEBUG
// NOTE: this assumes that os_init() has already been called but isn't a fatal error if it hasn't
void cmdline_debug_print_cmdline()
@@ -1450,6 +1458,21 @@
Cmdline_bloom_intensity = bloom_intensity_arg.get_int();
}
+ if ( listenergain_arg.found() )
+ {
+ Cmdline_listenergain = listenergain_arg.get_float();
+ }
+
+ if ( percent_flashtobang_arg.found() )
+ {
+ Cmdline_percentflashtobang = percent_flashtobang_arg.get_float();
+ }
+
+ if ( always_enforce_concurrent_sound.found() )
+ {
+ Cmdline_enforce_concurrent_sound_count = 1;
+ }
+
return true;
}
Index: code/cmdline/cmdline.h
===================================================================
--- code/cmdline/cmdline.h (revision 7567)
+++ code/cmdline/cmdline.h (working copy)
@@ -145,7 +145,10 @@
extern int Cmdline_no_grab;
#endif
+// Temp, only for evaluating new defaults
+extern float Cmdline_listenergain;
+extern float Cmdline_percentflashtobang;
+extern int Cmdline_enforce_concurrent_sound_count;
-
//extern char FreeSpace_Directory[]; // allievating a cfilesystem problem caused by fred -- Kazan
#endif
Index: code/nebula/neblightning.cpp
===================================================================
--- code/nebula/neblightning.cpp (revision 7567)
+++ code/nebula/neblightning.cpp (working copy)
@@ -21,10 +21,8 @@
#include "weapon/emp.h"
#include "network/multi.h"
#include "network/multimsgs.h"
+#include "cmdline/cmdline.h"
-
-extern int Cmdline_nohtl;
-
// ------------------------------------------------------------------------------------------------------
// NEBULA LIGHTNING DEFINES/VARS
//
@@ -439,24 +437,27 @@
// do some special stuff on the very first strike of the bolt
if(b->strikes_left == bi->num_strikes){
- // play a sound
- float bang;
- if(Nebl_bang < 40.0f){
- bang = 1.0f;
- } else if(Nebl_bang > 400.0f){
- bang = 0.0f;
- } else {
- bang = 1.0f - (Nebl_bang / 400.0f);
- }
- if(frand_range(0.0f, 1.0f) < 0.5f){
- snd_play(&Snds[SND_LIGHTNING_2], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
- } else {
- snd_play(&Snds[SND_LIGHTNING_1], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
- }
+ // play a sound
+ if (frand_range(0.0f, 100.0f) < Cmdline_percentflashtobang)
+ {
+ float bang;
+ if(Nebl_bang < 40.0f){
+ bang = 1.0f;
+ } else if(Nebl_bang > 400.0f){
+ bang = 0.0f;
+ } else {
+ bang = 1.0f - (Nebl_bang / 400.0f);
+ }
+ if(frand_range(0.0f, 1.0f) < 0.5f){
+ snd_play(&Snds[SND_LIGHTNING_2], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
+ } else {
+ snd_play(&Snds[SND_LIGHTNING_1], 0.0f, bang, SND_PRIORITY_DOUBLE_INSTANCE);
+ }
- // apply em pulse
- if(bi->emp_intensity > 0.0f){
- emp_apply(&b->midpoint, 0.0f, vm_vec_dist(&b->start, &b->strike), bi->emp_intensity, bi->emp_time);
+ // apply em pulse
+ if(bi->emp_intensity > 0.0f){
+ emp_apply(&b->midpoint, 0.0f, vm_vec_dist(&b->start, &b->strike), bi->emp_intensity, bi->emp_time);
+ }
}
}
}
Index: code/sound/ds.cpp
===================================================================
--- code/sound/ds.cpp (revision 7567)
+++ code/sound/ds.cpp (working copy)
@@ -18,8 +18,8 @@
#include "sound/acm.h"
#include "osapi/osapi.h"
#include "sound/dscap.h"
+#include "cmdline/cmdline.h"
-
typedef struct sound_buffer
{
ALuint buf_id; // OpenAL buffer id
@@ -1129,6 +1129,10 @@
// this is needed for 2D pan
OpenAL_ErrorPrint( alListener3f(AL_POSITION, 0.0, 0.0, 0.0) );
OpenAL_ErrorPrint( alListenerfv(AL_ORIENTATION, list_orien) );
+ if (Cmdline_listenergain > 0)
+ {
+ OpenAL_ErrorPrint( alListenerf(AL_GAIN, Cmdline_listenergain) );
+ }
// disable doppler (FIXME)
OpenAL_ErrorPrint( alDopplerFactor(0.0f) );
@@ -1407,24 +1411,33 @@
}
}
+ // Make sure that we are not going to play more copies of this sound than we should be
+ if ( Cmdline_enforce_concurrent_sound_count && (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
+ // If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
+ if (lowest_instance_vol <= new_volume) {
+ ds_close_channel_fast(lowest_instance_vol_index);
+ first_free_channel = lowest_instance_vol_index;
+ }
+ }
+
if (first_free_channel < 0) {
- // If we've exceeded the limit, then maybe stop the duplicate if it is lower volume
+ // Make sure that we are not going to play more copies of this sound than we should be
if ( (instance_count >= limit) && (lowest_instance_vol_index >= 0) ) {
// If there is a lower volume duplicate, stop it.... otherwise, don't play the sound
if (lowest_instance_vol <= new_volume) {
ds_close_channel_fast(lowest_instance_vol_index);
first_free_channel = lowest_instance_vol_index;
}
- } else {
- // there is no limit barrier to play the sound, so see if we've ran out of channels
- // stop the lowest volume instance to play our sound if priority demands it
- if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
- // Check if the lowest volume playing is less than the volume of the requested sound.
- // If so, then we are going to trash the lowest volume sound.
- if ( Channels[lowest_vol_index].vol <= new_volume ) {
- ds_close_channel_fast(lowest_vol_index);
- first_free_channel = lowest_vol_index;
- }
+ }
+ // still don't have a channel and
+ // there is no limit barrier to play the sound, so see if we've ran out of channels
+ // stop the lowest volume instance to play our sound if priority demands it
+ if ( (lowest_vol_index != -1) && (priority == DS_MUST_PLAY) ) {
+ // Check if the lowest volume playing is less than the volume of the requested sound.
+ // If so, then we are going to trash the lowest volume sound.
+ if ( Channels[lowest_vol_index].vol <= new_volume ) {
+ ds_close_channel_fast(lowest_vol_index);
+ first_free_channel = lowest_vol_index;
}
}
}
Trying to fix the sound code here, useful feedback has been requested.
Considering that part of what is being discussed is what soundcards people use and how effective the OpenAL support is on them, I would consider that useful, even if it isn't useful to you personally, don't assume that such information is irrelevant. I've fixed sound issues on a friend computer because they'd turned on some internal effects on their own card or it had a built in EQ that had been enabled.
As such, the discussion of soundcards used by members is not irrelevant.
Secondly, as Taylor stated, he is looking for a way to reduce gain on multiple occurences of the same sound, this, once again, relates to the fact that the problem might not be the actual sound itself, but the way the computer mixes it, which is also what I was talking about earlier.
-
Flipside: Reporting on ones sound configuration and setup while also providing feedback is more the point, not just some random divergence into talking about setups.
-
Agreed, more detail and a more formalised system would probably be needed, but the fact is that if someone is having problems with the sound code, it wouldn't hurt to know what card they are using. That's why I can't really contribute to the thread beyond suggestions, because I know that OpenAL support on my card sucks at the best of times, so I could be having problems that are purely related to that low level of support.
It's not the level of detail I have a problem with, it's the casual shrugging off of information because 'we're trying to fix the sound code here', there are polite ways and rude ways of doing things and a simple smattering of good manners, particularly outside of GD, is not such a big thing to ask.
I've stated on a few sound code threads that I felt it was more to do with the mixing of the sounds when the audio is particularly 'busy', though apparently Taylor found some other problems as well, and I stand by that belief, but if people want to consider my input irrelevant then fine.
-
Sound system setup can change everything about what works and what doesn't, so it never hurts to verify what someone has. Simply playing the game with headphones instead of a 7.1 sound system can give very different results. The 7.1 system can play sounds in a different place or moving in a weird direction, and headphones wouldn't show any of that. Hardware makes a bit of difference, particularly if the sound drivers have an effects mixer which can give strange results if any of that is enabled. OpenAL versions and how it's installed can make a difference as can what backend is in use. Also the platform in use can be a big factor, as OpenAL works quite a bit differently on Windows than it does for Linux and OS X. Far too much depends on the system and setup in question to assume that anything is just a problem with the code.
But I am definitely seeing a couple of code bugs. Things that weren't really an issue with the DS/DS3D code because of how the two operate (as far as I know, not an expert), but are an issue with OpenAL since it's a unified system. Cleaning up those issues will help deal with some 2D vs. 3D problems and make it easier to address the other issues.
I haven't quite figured out the true cause of the clipping issue, but it does seem to be related to a mixing problem with sounds that are in close proximity to each other. Tweaking the gain a bit manually on those individual sounds did a lot to reduce the clipping problems so it's now a matter of implementing a system which can handle that in an automatic manner, and hoping that it really works to fix the problem.
-
Taylor: :yes: :yes: :yes:
That's right, I grew a third thumb for that maneuver.
-
It is indeed quite relevant because, despite having tried for a while when I have been at my pc (hense, sorry, why I haven't popped up another video with the latest build when I have been on it), I haven't been able to repro the clipping described on Spoons machine on any of the builds, I assume, because of how much the Zonar can handle.
-
excuse me guys,but do you hear the capship warping effect?
and the capship explosion? the sound should be the Atomic.wav but what i only hear is the clusterboom sound.
i noticed that working on Diaspora... i think is not only our issue,but i think is a bug in the code.
Plus, the Capship engine not work...if you pass near a ship like the Colossus,you hear nothing IIRC.
thanks in advance for your help
BUMP
ehm...i quoted myself...
thanks again :)
Your post that you quoted wasn't even up for 8 hours before you bumped it, 24-48 hours is a more realistic timeline. If you want instant answers, use FS modding or #hard-light (assuming they have the answer for you), if you want researched answers, give the coders some time to research it.
Since you posted in this thread, I assume that is because the build that I posted breaks these sounds for you? I have not changed anything that should affect the playback of these sounds, so if this build is breaking it, go to the the nightly build forum (http://www.hard-light.net/forums/index.php?board=173.0) and try the builds there to locate where we broke the sounds in question.
For the record, I tested this last night, the correct warp, explosion, and engine sounds play just fine for me with retail assets in the trunk build and the build that I posted here. More than likely the problem is a mod data issue and the ship that is not playing the explosion or warp sound is missing the "capital" ship flag. I didn't get a chance to check on the specific requirements for engine sounds.
i've just Bump my post not for ask you an immediate answer for my issue,but because seems the discussion went out topic...that's all.
second: i'll try with the new build and see if there are some differences.
Anyway,i can't hear the atom.wav sound when a capship blows and the other issues in the retail build too,and is not due to the soundcard because all the Diaspora members noticed that.
Thanks for the help
-
Enough.
Can any non-to-the-subject posts be cleared out and no more be posted, please? Use your self-restraint guys thanks.
I think I nailed the flash-to-bang number needed, although obviously it's to personal taste so... video forthcoming.
Edit for video;
http://www.youtube.com/watch?v=4mry7YcdhaI
As it says in the description I'll fold it into the current long compilation video shortly and will end up;
http://www.youtube.com/watch?v=yBBONSZWTCA
-
Flash-to-bang is pretty solid in the video, but will it work in a mission with less lightning?
-
Still eagerly awaiting for updates from Taylor on this.
-
23:01 QuantumDelta • probably a good idea
23:01 QuantumDelta • how do you vary nebula lightning strikes normally btw?
23:01 Axem • what
23:01 QuantumDelta • in fred somehow?
23:02 Axem • RC?!
23:02 Axem • yeah QD
23:02 Axem • there's some storm settings in FRED
23:02 Axem • theyre rather coarse though i think
23:04 Axem • there's standard, active, medium and the ever favorite, emp
23:05 QuantumDelta • which one is the one used in the mission I've been videoing?
23:05 Axem • i dunno
23:05 Axem • which mission is it
23:06 QuantumDelta • uhmmm
23:06 QuantumDelta • with the warspite and lucidity and the two freighters....
23:07 Axem • Battle of the Wilderness?
23:07 QuantumDelta • might be?
23:07 Axem • +Storm: s_active
23:09 QuantumDelta • I wonder what the flash differences are..
23:14 Axem • http://pastebin.com/RtN7Nhx9
23:14 Axem • active is the heaviest
23:14 Axem • thats not the actual table
23:14 Axem • i just cut out the timing parts
23:46 QuantumDelta • I was gonna suggest some clever idea for how to change those timings so they'd work but uhh
23:46 QuantumDelta • 350-550, 500-900, 900-1850 sounds fine to me :<
obviously there are gameplay implications with changing the emp nebula flash though.. but sound wise those values sound right
-
change the EMP and sound so they are controlled in separate tables, e.g., you can have an 'active' storm, but the EMP effects are low. This would also be helpful for if they develop "hardened" fighters in a mission that are more insulated against EMP.
Good idea, yes/no?
-
How close are we to locking in reasonable numbers here? We'd like to start the RC phase and we were thinking if this is still needing some input we could commit the configurable stuff to trunk, and lock it in for a final 3.6.14 release.
-
My offered numbers are based on a few tests, of which the comparison is visible (in terms of percentages of sound) in my last video with the input from cyborg making the note to factor in that the other nebulae have different levels.
It just needs a bit of legwork from some other people to see if it's not just 'to my tastes' or so.
-
How close are we to locking in reasonable numbers here? We'd like to start the RC phase and we were thinking if this is still needing some input we could commit the configurable stuff to trunk, and lock it in for a final 3.6.14 release.
Well, only 2 people have actually offered any data to me, which results in 3 data points, which IMHO is not enough.
Also Taylor is working on some more proper fixes that may actually remove the need for any of my tweaks.
-
i think this is one of the things that really REALLY shouldnt be hard-coded to the engine, as what might sound good with one set of effects, might sound crap with another set of effects.
Come one coders, you're not supposed to only keep everything retail-like and hard-coded, add another table for things like this and give us modders ways to work out things on our own as well.
-
i think this is one of the things that really REALLY shouldnt be hard-coded to the engine, as what might sound good with one set of effects, might sound crap with another set of effects.
Come one coders, you're not supposed to only keep everything retail-like and hard-coded, add another table for things like this and give us modders ways to work out things on our own as well.
With respect to the speakers and audio cards, find the settings (with retail assets) that you like the best with whatever you play the game with. I am going to make whatever the consensus is the defaults for the engine. The cmdline flags are not staying.
-
Okay, so to help get the RC cycle going, I decided to help.
http://lazymodders.fsmods.net/files/NewSoundCodeTestMission.rar
Here's some test missions for people to play to experiment around with the settings.
ClippingTest.fs2 tries very hard to clip audio. 12 Fighters all jump in right next to the player at the same time, then 6 mjolnirs fire at the same time.
My experience with that: -alwaysenforce + -listenergain around 0.5 - 0.65 sounded the best. (I preferred 0.5 personally)
NebTest.fs2 will cycle through the different storm types in FreeSpace to test -percent_flashtobang. Every 25s, a new storm type. I liked 30 in my opinion, though seeing close lightning without any sound was kind of odd. s_active is still too noisy for me though :p
-
Using on-board RealTek on this rig (:(), 5.1 setup, soft_oal.dll as "Speakers (RealTek High Definition Audio) via DirectSound"
I used ' -alwaysenforce -listenergain 0.5 -percent_flashtobang 50'
Which seemed pretty good in all cases. The beams still clipped ever so slightly, but much better than it was.
-
With respect to the speakers and audio cards, find the settings (with retail assets) that you like the best with whatever you play the game with. I am going to make whatever the consensus is the defaults for the engine. The cmdline flags are not staying.
"The cmdline flags are not staying" part is what got my red flag waving around, as it implies that you will hardcode it and be done with it
-
Which is the best way to ensure a Retail like level of consistency in regards to particular environments.
If you want more expansion outside of that for a mod end, then you're looking at a modular sounds.tbl and using the sound_env.tbl for your mod, not dealing with the elements that these options are going to be setting up.
-
Does the sound problem happen for all cards ?
Ive never heard it could that be because my soundcard is capable of 128 simultaneous sounds ?
also could it be an openal problem would sending the openal devs a bug report be worthwhile ?
-
Does the sound problem happen for all cards ?
in various amounts, yes.
Ive never heard it could that be because my soundcard is capable of 128 simultaneous sounds ?
You just might be one of the lucky ones who have cards which have proper hardware mixers, but even with my Audigy 2ZS i have these problems sometimes.
also could it be an openal problem would sending the openal devs a bug report be worthwhile ?
Doubtful.
-
So, as promised, I ran a lot of testing. I modified the .patch to compile to Antipodes, since that is what I do most of my testing with, but with that in mind, I will be repeating all of my tests again with Trunk.
I also need to test under "Generic Software" as well, which I will do and either update this post, or make an additional post (which ever is preferred)
- FSO Selection: Speakers (Creative SB X-Fi) via DirectSound
- Sound Device: X-Fi Fatality XtremeGamer
- Driver: Creative Sound Blaster X-Fi series driver 2.18.0015
- OpenAL version: 2.0.7.0 Installer (OpenAL 1.1; OpenAL32.dll version 6.14.357.24; wrap_oal.dll version 2.2.0.5)
- OpenAL Soft (version and type): 1.13, soft_oal.dll
- Speaker Setup: 4.1 (Windows: Quadraphonic)
- Settings found Acceptable: -alwaysenforce -listenergain 0.5 -percent_flashtobang 55
As for the hardcoded stuff: What we are looking at and for HERE are being able to accurate represent and reproduce the "Retail" environment for effects playback that is consistent across the board.
OTHER things, like a flexible modular sounds.tbl and active use of the sound_env.tbl (which practically NOBODY is currently familiar with and I would LOVE for taylor, if he could one more time, post that and explain it for people so we can get it into the wiki) are what will allow for the non-hardcoded leverage of taking advantage of this new sound code. To be able to allow mod's to have the ability to control environment, sample playback amounts and/or gain and everything else is NOT what the purpose of THIS current testing is about. Those ARE issues and they DO need to be addressed, but not within the scope of THIS testing. Yes, it WILL be nice also being able to control these values outside of hard coded values. But we NEED the hard coded values FIRST to establish what the defacto baseline is so that pioneering sound engineers (no pun intended) know that what is heard on one system has a better chancre of still sounding just like that on another system.
-
:bump:
Would be a shame to let this issue slip into oblivion again when there was finally some progress getting made
-
Don't worry, it won't. I've been too busy this week to follow up due to a global summit at work, but as soon as that's over I'm going to be diving straight into getting something in to rectify the situation enough for the RC.
-
Don't worry, it won't. I've been too busy this week to follow up due to a global summit at work, but as soon as that's over I'm going to be diving straight into getting something in to rectify the situation enough for the RC.
Excellent :yes:
-
if is possible, i wanna notice that the atom.wav sound is tied only at Flags: "Capital" in ships.tbl.
If the Flag is "supercap" or "freighter" the atom.wav not work.
Hope you can fix this bug :)
-
Is it Mantis'd? Be a good idea to point out the number if so, and it probably won't get fixed if not.
-
ehm...i don't know use mantis :(
Could you please do this for me?
Thanks in advance :)
-
ehm...i don't know use mantis :(
Could you please do this for me?
Thanks in advance :)
http://scp.indiegames.us/mantis
register there and open a new issue. If you are unsure on how to actually format your new issue, take a look at the previously added issues and format accordingly.
-
i am lazy :P
ok i'll do it...
-
i am lazy :P
ok i'll do it...
Please do. Also note that issues on Mantis tend to get more priority than bug reports on the forum or bug mentions on IRC.
-
did it :)
-
I did some checking, and this thread (http://www.hard-light.net/forums/index.php?topic=77314.msg1550263#msg1550263) might be relevant here too.
Also Mantis'd.
-
A more permanent version of the previous build has been committed as revision 7814 in preparation for 3.6.14 RC stage. See the commit message for details as it is a little different that what was here previously. Of note is -listenergain is not a cmdline flag in the committed version and -alwaysenforce has been inverted as -donotenforce.
What was committed is consensus of this thread, which is locked in as the defaults for the RC. The flags -donotenforce and -percent_flashtobang will be removed before .14 final. percent_flashtobang will remain adjustable via lightning.tbl in the .14 final.
-
I think I figured out a good compromise to the sound code problem. Include both in the port, make a launcher flag that allows one to use the old sound code instead of the new one, and add a corresponding checkbox in the 'features' tab of the launcher.
Now users can use whichever version of the sound code they prefer. Problem solved.
-
Except we can't. The two can't exactly coexist. It was a rewrite of much of the fundamental behavior of the code, not just some tweaks here and there. Since you're new, I'll take that as an honest mistake, but generally programmers don't like being told how to do their jobs by non-programmers.
Also IssMneur, the idea was to commit it to just the 3.6.14 branch now that we have it :P
-
Except we can't. The two can't exactly coexist. It was a rewrite of much of the fundamental behavior of the code, not just some tweaks here and there. Since you're new, I'll take that as an honest mistake, but generally programmers don't like being told how to do their jobs by non-programmers.
Also IssMneur, the idea was to commit it to just the 3.6.14 branch now that we have it :P
Bah, you need to copy the patch from somewhere :D Besides, we don't know how long it will be till we have the proper fixes to the sound code. But you or I can revert it if you like.