Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: z64555 on July 05, 2012, 10:15:42 pm
-
I actually want to get started on this, but it's probably likely that another coder is interested and/or people have comments. :nervous:
This feature surfaced after this other request (http://www.hard-light.net/forums/index.php?topic=81216.0;topicseen) was made. Short story is that Spoon chimed in about how it would be nice to assign multiple launch sounds per weapon, and I mentioned that another mod project I had worked on (DF:BHD if your wondering) had something called Sound Sets.
- Any
sound sound set can have its pitch and/or volume randomized by some defined amount. - Sounds can be grouped into sound sets. When the sound set is called, one of the sounds in the set is played.
- Sound sets can either sequentially cycle (forward or backward) between the included sounds, or randomly pick a sound whenever the sound set is played.
The above strike-through edit is due to the fact that:
- I forgot that the DF:BHD engine only did this in soundsets, and not per individual sound and
- It's probably a better idea to do pitch and/or volume randomization only within the sound sets, anyway.
Possible table format for soundsets:
#Sound Sets
$Set: 0 ;; The ID number for this set
+Cycle: random ;; Will cycle randomly. Defaults to forward cycling (top of the list down)
$Sound: 10 ;; The ID number of the first sound
+Randomize Pitch: 0.3 ;; Pitch Randomization percentage ( between +/- 30%)
+Randomize Volume: +0.1 ;; Volume Randomization percentage ( up to +10%)
$Sound: 11 ;; Second Sound ID
$Sound: 12 ;; Last sound in this set
$Set: 1
$Sound: 13
#End
The + and - there is an additional feature, which would essentially allow the tabler some flexibility for the randomization. The value is a % of the volume or pitch (might actually be the .wav's total playtime), and has to be a float value to allow for fine adjustments (especially for randomizing the pitch). [See below]
Next problem for the .tbl's would be to figure out how to differentiate between individual sounds and sound sets with the existing system. Ideally, the implementation would be backwards compatible... so if you don't specify to use a sound set somewhere, the sound ID will be used.
A better method to define the range the volume, pitch should randomize in would be like so:
+Randomize Pitch: 10.0, 10.0 ;;First value is positive (higher pitched), second value is negative (lower pitched)
;; ex. values of 10.0, 10.0 would result in a pitch range of +10.0% to -10.0% of the sound's original pitch
As for the differentiation between sounds and sound sets, we could overloard the existing sound function(s) with an optional flag:
sound_function( ... , bool Is_a_sound_set = FALSE )
(No, that's not the actual sound function. :P)
Lastly... Sound set's might also include sub-groups to be used in particular environments. Although I personally think it would be better to come up with a way to apply distortions to the sounds/sound sets depending on the environment the player is in (read: atmospheric vs. space), for now, it may be good to make an $Environment Group: option.
#Sound Sets
$Set: 0 ;; The ID number for this set
+Cycle: random ;; Will cycle randomly. Defaults to forward cycling (top of the list down)
$Environment: 0 ;; Environment sub group. Defaults to 0 if not specified
$Sound: 10 ;; The ID number of the first sound
+Randomize Pitch: 0.3 ;; Pitch Randomization percentage ( between +/- 30%)
+Randomize Volume: +0.1 ;; Volume Randomization percentage ( up to +10%)
$Environment: 1
$Sound: 11
$Sound: 12
#End
-
Interesting.
This is a large undertaking. The FSO sound code is only ready for this in spirit. The largest problem for implementing this would be extending the sound information enough to carry the metadata required to do this and to correctly reset channels after having used these more advanced OpenAL features.
The functions in question would be ds3d_play and ds_play, but the problem for you in implementing this feature would be that both functions are actually too low level for what you are wanting to do, so you would have to implement a shimlayer that would allow these soundsets to be implemented using ds3d_play and ds_play.
As far as implementing the interface to this feature, please, please don't use another set of numbers that are interchangeable but orthogonal to the stuff that is in sound.tbl. Instead use names (probably force them to start with sset_ or something similar (remember identifiers in FSO need to be less than 32 chars)) and modify/extend parse_sound (which is used by the weapons.tbl parser to do a couple of neat tricks with sound filenames already). This will allow a tabler to use a soundset just like they could a filename. Also, remember this is going to basically require that you do this for everything or nothing because otherwise SCP is going to be forever adding support for this feature one location at a time.
As for the proposed table format. I already went over the use of numbers, but I feel so strongly about it I am going to repeat it, just don't number these as well. Also, make sure that this table can be used as a modular table because otherwise this feature is going to be a mod data bug farm. I would also suggest allowing the sets to include sounds based on its filename like weapons.tbl does already. Is the randomize pitch and volume per sound or per soundset?
A better method to define the range the volume, pitch should randomize in would be like so:
+Randomize Pitch: 10.0, 10.0 ;;First value is positive (higher pitched), second value is negative (lower pitched)
;; ex. values of 10.0, 10.0 would result in a pitch range of +10.0% to -10.0% of the sound's original pitch
This is a bad idea. Just make it +Randomize Pitch: and two numbers between -100 and 100 (or whatever range makes sense). That is, require the tabler to specify a negative number to get a negative pitch shift. This way a tabler (and I know one will ask) can use a +10% to +20% random shift. Also, drop the comma in the data and just make it whitespace because the comma just complicates the parsing of the data and is different than how the rest of the .tbls are parsed.
As for the differentiation between sounds and sound sets, we could overloard the existing sound function(s) with an optional flag:
sound_function( ... , bool Is_a_sound_set = FALSE )
(No, that's not the actual sound function. :P)
Not a real fan of this, because the current sound functions already have several default variables, I would prefer if all sounds were assumed to be in a soundset of 1 with the default (read no) variations and they are assigned a name of their specific number.
Lastly... Sound set's might also include sub-groups to be used in particular environments. Although I personally think it would be better to come up with a way to apply distortions to the sounds/sound sets depending on the environment the player is in (read: atmospheric vs. space), for now, it may be good to make an $Environment Group: option.
#Sound Sets
$Set: 0 ;; The ID number for this set
+Cycle: random ;; Will cycle randomly. Defaults to forward cycling (top of the list down)
$Environment: 0 ;; Environment sub group. Defaults to 0 if not specified
$Sound: 10 ;; The ID number of the first sound
+Randomize Pitch: 0.3 ;; Pitch Randomization percentage ( between +/- 30%)
+Randomize Volume: +0.1 ;; Volume Randomization percentage ( up to +10%)
$Environment: 1
$Sound: 11
$Sound: 12
#End
Again. Use names for the Environments and default to the first one listed and let the FREDer pick the environment with a sexp, that way they can do whatever funky thing they want.
Anyway, this is my 30 minute shoot from the hip response to this, hopefully it is useful to you.
-
I actually experimented with this at the time it was posted first and I already have an addition to the sound code which adds classes that are capable of holding informations like this. I also have another addition to the sound parsing code which adds modular table support for the sound table which should work nicely.
Now the more important part is, like Iss Mneur pointed out, that the sound play functions (snd_play and friends) need to be able to use this information. I'd be in favor of having a generic SoundInformation class which could be passed to the sound play functions which encapsulates a game_snd or a sound set (meaning that we have a game_snd class and a SoundSet class which extends the SoundInformation class).
Now the other problem is that currently a reference to a sound is saved as an int which is an index into the Sounds vector which is obviously not suited to be used in conjunction with the proposed sound sets. A solution would be to change the indexing values to be of a special type which could hold the information needed to reference either a plain sound or a sound set.
Also I'm attaching a patch containing the modular sound table parsing changes in case somebody would like to take a look at it as that would make it much easier to implement this feature if the sound table is already modular.
[attachment deleted by a ninja]
-
One thing that might be desirable (either as an option or not) would be making a sound list never play the same sound twice in a row. Meaning that whenever triggering a sound list sound, the game would check which one was picked from the list the last time, and pick any other sound than that.
-
One thing that might be desirable (either as an option or not) would be making a sound list never play the same sound twice in a row. Meaning that whenever triggering a sound list sound, the game would check which one was picked from the list the last time, and pick any other sound than that.
That's item #3 in the first quoted list. :P
-
Also I'm attaching a patch containing the modular sound table parsing changes in case somebody would like to take a look at it as that would make it much easier to implement this feature if the sound table is already modular.
Any chance you can share with us how it works? (As in sounds-XXX.tbm, what the syntax is, etc.)
-
+Randomize Pitch: 0.3 ;; Pitch Randomization percentage ( between +/- 30%)
+Randomize Volume: +0.1 ;; Volume Randomization percentage ( up to +10%)
Why cap it? Or at least... why at 30%? I figure as long as it doesn't break the game, might as well give modders as big a range to play with as possible.
-
I can't really offer anything but my support for this from the sidelines
-
Any chance you can share with us how it works? (As in sounds-XXX.tbm, what the syntax is, etc.)
The table uses -snd.tbm as modular table prefix and the syntax stays the same for new entries. If you want to modify an existing entry then you use +nocreate to tell the parser that it should not create a new entry.
So if you want to change the retail tracking sound which was defined like this:
$Name: 0 trk-loop.wav, 0, 0.40, 0with the sound in my_cool_sound.wav you would need the following entry:
$Name: +nocreate 0 my_cool_sound.wav, 0, 0.40, 0
-
What happens if you specify a sound index in a modular table that is taken in sounds.tbl.. or if you specify an index that is not next on the list? (Sounds.tbl ends at 195, and you specify 203)
More specifically, how can one append new sounds to the list of interface sounds. for example?
-
The index isn't really an index into the storage vector but rather just a unique number so every new entry just gets appended to the vector. If you specify an ID which is already taken and you're not using +nocreate then a warning will be displayed saying that the specified ID already exists.
Adding interface sounds isn't treated specially so it should work as usual.
-
This is win and has been needed for a LOOOOOONG time. I shall test.
Although.. would it be possible to get a flag like +nocreate, but that instead just appends the new sound after the ID of the latest in the section?
My specific usage is with the mainhall packs I've been working on. With that capability, anyone can drag-n-drop one of the Mainhall VPs and the sounds won't cause errors like that because they are appended to the end of the list. This is helpful because the mainhall.tbl (as well as some other tables, iirc) can reference sounds by sound file instead of ID number, so ID number doesn't matter.
Of course, then you have to worry about what to do with multiple .tbms... which you could just append in the order they are loaded or something?
I dunno.. just thoughts.
-
It is possible to search for the next free ID after the specified ID but that would be a bit harder to implement with no big improvement as you could just pick a number at random and hope that it isn't taken yet.
-
Well is the Wiki still current in saying "Note: These MUST be sequential, no gaps are permitted. Also note that some indices are reserved for hardcoded effects, see here for a full list. You can use empty entries as padding to fill out any gaps."?
-
Well, there's nothing code wise that would need that AFAICS so I guess that that information is just outdated.
-
@m!m: Why are you passing the "sounds" vector by value to gamesnd_lookup_signature? Also there is a typo in the comment on line 93 of the patch.
Well is the Wiki still current in saying "Note: These MUST be sequential, no gaps are permitted. Also note that some indices are reserved for hardcoded effects, see here for a full list. You can use empty entries as padding to fill out any gaps."?
That warning is still valid. Nothing that I see in m!m's patch changes that warning.
The requirement is a result of most sounds indexing directly into the Snds vector and the Snds_iface vector, which means that the vector has to be contiguous and in the same order as retail.
IIRC, only parts weapons.tbl and mainhall.tbl really uses the lookup code (any place in the parser that is serviced by parse_sound basically). This is something I never got back to fixing after Vectoring sounds.tbl.
-
So, it would definitely be helpful for an +Append option. That would allow us to much more dynamically include special sounds with weapons and ships. (According to the Wiki, certain flags in ships.tbl accept the string filename or ID.)
-
@m!m: Why are you passing the "sounds" vector by value to gamesnd_lookup_signature? Also there is a typo in the comment on line 93 of the patch.
I don't know why I'm doing it by value :doubt: I'll fix that later...
That warning is still valid. Nothing that I see in m!m's patch changes that warning.
The requirement is a result of most sounds indexing directly into the Snds vector and the Snds_iface vector, which means that the vector has to be contiguous and in the same order as retail.
IIRC, only parts weapons.tbl and mainhall.tbl really uses the lookup code (any place in the parser that is serviced by parse_sound basically). This is something I never got back to fixing after Vectoring sounds.tbl.
I'm not sure but the signature of the game_snd structure is never used as an index into the Snds (or Snds_iface) vector, every sound reference in the code is (or should be) parsed by parse_sound which results in actual indexes but every new game_snd instance is just added to the vector if I'm not missing something here.
-
True. Any place that you can use a string filename then its a pretty good bet that it does use the lookup functions and as such is not affected by moving of things in the sound table.
I think the better solution would be to allow the .tbl or .tbm to have a -1 as the id and have the parser just defer assigning them the actual id number until after all sounds have been parsed. It could then go through the deferred list and append them all to the end of the sound.tbl this way no problems with accidentally stomping on someone else. Remember tbms do not guarantee ordering.
An alternative, that would be more work, but less trouble all around, would be to take a page out of ships.tbl and weapons.tbl and just don't use numbers at all and refer to sounds by filename or allow a soundname to be specified in the sounds.tbl/.tbm. This way the numbers are completely hidden from the tabler and much less likely to cause problems with .tbms. The existing sound indexes would be assumed to be named their number just like CommanderDJ did with the mainhalls.
I'm not sure but the signature of the game_snd structure is never used as an index into the Snds (or Snds_iface) vector, every sound reference in the code is (or should be) parsed by parse_sound which results in actual indexes but every new game_snd instance is just added to the vector if I'm not missing something here.
Yes, I quite sure you are missing something.
Most of the sounds in the engine do are not parsed by parse_sound (or are not parsed all, in the case of most sounds). This means that they can only be changed by changing the entry at its index in sounds.tbl or replacing the soundfile itself. This reality is what prompted torc to asked for the ability to do player impact sounds per weapon.
For example (because I was just looking at this code for mantis 2266) take FlakLaunch (sound.tbl id 116) (the sound of a flak gun firing), and boom_4 (sound.tbl id 117) (the sound of a flak shell exploding) are both referred to in code with a define that has the value of 116 or 117, respectively. Most entries in the sound.tbl are this way, in particular the interface and misc sounds are all referred directly by their index in sounds.tbl.
I think the defines are in gamesnd.h.
-
I was talking about the sound definitions which were added in addition to the hard coded indexes, I'm sorry if that wasn't clear in my posts, used in the code which obviously need to stay in those places and if there are places where sounds are parsed without the parse_sound function then those need to be changed and I'll do so if you can point out where that happens.
I already thought about extending the syntax of a sound definition to have a cleaner syntax which could include a name option and using the current signature numbers as the default name will make it much easier to manage the sound entries :nod:.
-
Oh I see. Indeed you are right about that, so we were just talking past each other then.
I have updated the entry on the wiki to reflect the current requirements of the sound.tbl.
-
I think the better solution would be to allow the .tbl or .tbm to have a -1 as the id and have the parser just defer assigning them the actual id number until after all sounds have been parsed. It could then go through the deferred list and append them all to the end of the sound.tbl this way no problems with accidentally stomping on someone else. Remember tbms do not guarantee ordering.
An alternative, that would be more work, but less trouble all around, would be to take a page out of ships.tbl and weapons.tbl and just don't use numbers at all and refer to sounds by filename or allow a soundname to be specified in the sounds.tbl/.tbm. This way the numbers are completely hidden from the tabler and much less likely to cause problems with .tbms. The existing sound indexes would be assumed to be named their number just like CommanderDJ did with the mainhalls.
Those seem like better options than my idea.
-
+Randomize Pitch: 0.3 ;; Pitch Randomization percentage ( between +/- 30%)
+Randomize Volume: +0.1 ;; Volume Randomization percentage ( up to +10%)
Why cap it? Or at least... why at 30%? I figure as long as it doesn't break the game, might as well give modders as big a range to play with as possible.
This is so that modders can define a pitch range to their liking for that particular sound within that particular set. In case you did not know, it is usually much easier to maintain hi fidelity when lowering the pitch, but not when raising the pitch (read: awesome bass vs. ear-splitting garble).
I already thought about extending the syntax of a sound definition to have a cleaner syntax which could include a name option and using the current signature numbers as the default name will make it much easier to manage the sound entries :nod:.
This is basically what they did for DF:BHD, their version of the sound table assigned a name for each .wav that would be used elsewhere. For the most part, I couldn't figure out any advantage to doing this other than being able to re-use a single .wav but with different volumes. Case in point: a majority of the names assigned to each wave had the same exact name as the wav (except without the .wav file extension).
-
Here is a patch which implements the proposed name mechanism and a new syntax for the sound definition.
The new syntax looks like the following sample entry:
$Name: <name>
[+nocreate](optional)
+Filename: <sound filename>
+Preload: Yes|No
+Volume: <float>
[+3D Sound:
+Attenuation start: <start distance>
+Attenuation end: <end distance>](optional)
If the +Filename option is not present after the name of +nocreate then the entry will be parsed using the default syntax to remain backwards compatible.
[attachment deleted by a ninja]
-
How does that syntax work with the retail table? I'm just confused because the retail entry layout is vastly different from your (much preferred) +entries.
This...
$Name: 6 breakup.wav, 0, 0.60, 1, 100, 800
Could be this...
$Name: 6
+Filename: breakup
+Preload: no
+Volume: 0.60
+3D Sound: 1
+Attenuation start: 100
+Attenuation end: 800
Right?
-
Yes that's how it works with the exception that you still need the .wav extension on the +Filename option.
-
How does that syntax work with the retail table? I'm just confused because the retail entry layout is vastly different from your (much preferred) +entries.
If I'm reading the .patch right, it looks like he made it so that the parser will detect which style of entry is used and jump to the appropriate stuffer...
-
Right, so if +filename is present, you can refer to the sound as that and it really doesn't matter what $name is set to? (will it overwrite files with the same $name in that case?)
-
No, the value you give to $Name is the name you use to refer to this sound in the other tables.
-
I'll be testing the modular sounds patch tonight... anyone else tested it yet?
-
Can such thing be done to particles/explosions as well?
-
Can such thing be done to particles/explosions as well?
:wtf:
Tested the modular sounds and it works great. It loads the retail data just fine. I added sounds to both sections (#Game, #Interface, NOT #Flyby) and they all worked. I modified sounds in those sections which also worked.
One thing I found odd though. Retail sounds.tbl expects a 'type' to be specified for 3D sounds. Your TBM (under the new syntax) does not want a type integer there. I suppose that's because under the current code sounds will either be 3D or not.. so those integers are unnecessary. Makes sense, just took some testing to figure that out due to the lack of instructions with this patch... :nervous:
EDIT: How does the modular stuff work for the #Flyby section?
EDIT2: Trying to override an entry with a tbm results in duplicate sound warning. Warning persists when using +nocreate.
In fact...
$Name: 66
+nocreate
+Filename: emptymsg.wav
+Preload: No
+Volume: 0.50
Caused it to look for a float value (old parsing method) in the playse of +filename: emptymsg.wav.
-
As far as I can tell from the patch, the #FlyBy section would work like this:
#Flyby Sounds Start
$Terran: 0 ; * Terran ship1 flyby player sound (3d sound)
+Filename: T_flyby1.wav
+Preload: No
+Volume: 0.75
+3D Soud: 1
+Attenuation start: 200
+Attenuation end: 400
$Terran: 1 ; * Terran ship2 flyby player sound (3d sound)
+Filename: T_flyby2.wav
+Preload: No
+Volume: 0.75
+3D Soud: 1
+Attenuation start: 200
+Attenuation end: 400
$Vasudan: 0 ; * Vasudan ship1 flyby player sound (3d sound)
+Filename: V_flyby1.wav
+Preload: No
+Volume: 0.85
+3D Soud: 1
+Attenuation start: 200
+Attenuation end: 400
$Vasudan: 1 ; * Vasudan ship1 flyby player sound (3d sound)
+Filename: V_flyby2.wav
+Preload: No
+Volume: 0.85
+3D Soud: 1
+Attenuation start: 200
+Attenuation end: 400
$Shivan: 0 ; * SHIVAN ship1 flyby player sound (3d sound)
+Filename: S_flyby1.wav
+Preload: No
+Volume: 0.75
+3D Soud: 1
+Attenuation start: 200
+Attenuation end: 400
$Shivan: 1 ; * SHIVAN ship1 flyby player sound (3d sound)
+Filename: S_flyby2.wav
+Preload: No
+Volume: 0.75
+3D Soud: 1
+Attenuation start: 200
+Attenuation end: 400
#Flyby Sounds End
... and the value right after the $Species can apparently be anything at the moment... so long as the first entry is for the Fighters and the second is for the Bombers.
-
Can such thing be done to particles/explosions as well?
Sure, you just have to find someone who has the time to do it...
z64555 is right about the #Flyby section. It uses the same syntax but doesn't support the +nocreate tag. Sadly if you want to change the flyby sound you will have to duplicate all entries for it to work, I need to fix that later...
EDIT2: Trying to override an entry with a tbm results in duplicate sound warning. Warning persists when using +nocreate.
In fact...
$Name: 66
+nocreate
+Filename: emptymsg.wav
+Preload: No
+Volume: 0.50
Caused it to look for a float value (old parsing method) in the playse of +filename: emptymsg.wav.
:banghead: I said that wrong. +nocreate has to be located right before the name itself to work. I also forgot to say that you may not use spaces inside the name as that will trigger the old parsing method...
-
So what's the next step before we can haz modular sounds in trunk?
-
Well I couldn't find any issues with the current patch so a code review would be the next step.
A thread split may also be appropriate as this thread is not about the modular sounds table but about a feature request...
-
I reviewed m!m's patch, making some very minor edits (mostly with const-correctness and the like). It's committed in r9062.
-
I reviewed m!m's patch, making some very minor edits (mostly with const-correctness and the like). It's committed in r9062.
TO THE WIKI!
Edit: Oh? Somebody made the adjustments before I did! YAAAAY! :warp:
Edit2: TY MJN (and m|m , and Goober too)
-
Thanks mjn.mixael and Goober. I just did two minor edits to the wiki to document behavior that isn't obvious and may result in strange errors.
-
Indeed. This was a much desired feature of mine... Now that that's done.. we can take a further look at the other features requested in this thread.
-
I'm currently in the process of implementing this request and already mode some progress. The sound play functions now also accept an abstract class which represents a sound information. Currently there is the normal game sound information which just returns the game sound data and gives default values for every other option and there is the SoundSet class which represents the requested sound sets which can contain multiple sounds and can vary the pitch, volume and for 2D sounds the panning of the played sound.
It's not done yet but I will post a patch later today as a backup as I will be leaving for a 3 week vacation tomorrow so don't expect updates in that time period.
EDIT: Patch is attached, I only checked if it compiles and is able to play sounds.
-
With some minor modifications to the previously posted patch I can finally present a first test build of the sound set feature: http://www.mediafire.com/?rbwg1bo4c5bu5dx (http://www.mediafire.com/?rbwg1bo4c5bu5dx)
To specify a sound set you add either the section #Sound Sets after #Game Sounds End for game sounds (ended with #Sound Sets End) or #Interface Sound Sets (ended with "#Interface Sound Sets End) after #Interface Sounds End for interface sounds.
The sound set is defined with the following syntax:
$Set: <name>
[+Cycle: RANDOM|FORWARD|BACKWARD] (defaults to RANDOM, compares case-insensitively)
[$Default:] (specifies the default sounds to be used in an environment which isn't configured)
<entries> (See below)
[$Environment: <environment name>
$Sound: <sound identifier>
+Volume randomize: <float: minimum> <float: maximum> (The amount to raise (positive number) or lower (negative number) the volume of the sound when played, given in percent, has no range limitations)
+Pitch randomize: <float: minimum> <float: maximum> (The pitch value to be set, minimum may not be lower than zero, given in percent)
+Pan randomize:: <float: minimum> <float: maximum> (The amount to alter the pitch, accepts values from from -2.0 to 2.0, given in percent)]
($Sound can be repeated)
Other notes:
- A sound set can be used by simply using its name just like you reference a sound currently
- You have to specify at least $Default or one $Environment entry
- You may only specify sounds which are defined as game sounds to remove the possibility of an endless recursion
- The patch also removed the need to specify the hard coded sounds in the exact order, they are now also referenced using the numbers as names
- Currently the parsing code does not support the modification of a sound set, although I will add it in the future
- Sound sets may not have the same name as a game sound which isn't checked currently, a check will be added in the future
Thanks for your kind attention,
m!m
[attachment removed and sold on the black market]
-
Awesome! Thanks much, m!m, I'll see that I get to playing around with this shortly.
Edit: Managed to get a few cursory tests done:
- There's a noticable echo on voices
- There's a noticable variation in the volume of voices
- When pressing the afterburner key, any voice that's currently talking is abrutly cutoff, and sometimes has a "record scratch" effect
- Both the supplied release and debug build failed to load my #Sound Sets section. :(
-
I can't reproduce any of those issues using the test builds I posted but there was a mistake with how the pitch was calculated. I updated the patch and the test build in the post above, maybe that will fix your issues.
-
great job m!m... i'll make some test ASAP!... for who is interested: i'm working on the restoration of ALL the FS2 sounds...this would be a good implementation, and if this patch works good i could make new sounds fx based on the new patch :)
-
Yea... um...
Something's not quite right on my end.
I've attached two logs, one of the SoundSet d build and one of the r8095 (no SSE) d build for comparison.
For both, I'm running retail data - no SoundSet entries in the sounds.tbl. For the SoundSet build, I get CTD's and (if I'm lucky for it to keep running long enough) .ani frame corruption.
I'm compiling a build with the patch applied to whatever's currently in trunk to see if that fixes it on my end...
[Edit] yeah, it's either something up with the Non-SSE builds or something in the patch that's making it not work for me.
[Edit2] Nope. SSE builds have the same problem. :(
[attachment removed and sold on the black market]
-
Sorry for not answering the last two days but I've been out of town without time for HLP.
I still can't reproduce your issue and the logs don't show anything unusual.
Can you try to get a stacktrace of the CTD? Maybe that will show what's wrong there...
-
Small :bump: here to check if anyone tested this or if you have resolved that weird crash thing z64555.
I'd also like to ask for a code review as I added a few new classes within their own files and I'd like to know if that code style can be kept or if the classes should stay inside the gamesnd.cpp/.h files.
-
I've got a hunch that it has to do with Valathil's new .ani code. Apparently it doesn't like OpenGL 1.4 (and guess which version I just happen to have :banghead:)
Hopefully later tonight or tomorrow I can try a pre-9109 build with the SoundSet code to see if that is indeed the case.
[Edit] It's definitely the 9109 revision that's giving me trouble.