SoundUtils

[Rising_Dusk]

Originally Posted by Anachron

You should add an option what player to play the sound to

Uh, well, I am pretty sure that the following won't desync:

JASS:

if GetLocalPlayer() == MyPlayer then
    call RunSound(MySound)
endif

Furthermore, though, when does it ever make sense for only one player viewing an action to hear the sound? If I shoot a missile at a point, all players should hear the explosion, stuff like that.

[Fledermaus]

When a player was hit by an explosive and they've got that weird screeching noise you hear in movies? :p

[Rising_Dusk]

Wouldn't that apply to anyone in range, though, in which case a 3-D sound would work great? (With different range cutoff settings than default, of course)

[Fledermaus]

Not if you've got Divine Shield, or it's team V team and your explosives don't TK.

But yeah, enough silly buggers. The local block should be fine for people who ever want to locally play a sound, don't really think the system needs to support that but it couldn't hurt to.

[Rising_Dusk]

I guess I can see the applications of that in that scenario. I think the local block should be OK. If Ani wants me to, I can add RunSoundForPlayer, though.

[Captain Griffen]

Useful library (god I hate WC3 sounds' implementation sometimes, it's so annoying). Anyway, correct me if I'm wrong, but won't the H2I - min handle implementation bug out if the handles on the map (rather than just the sounds on the map) exceeds 8191?

As to for local blocks, putting it in local blocks would be fine for running, but in combination with releasing when done, you'll run into issues, won't you? Since you may later on get new sound being created on some systems but not others, due to different numbers of sounds release / in the stack.

[Rising_Dusk]

Originally Posted by Captain Griffen

Anyway, correct me if I'm wrong, but won't the H2I - min handle implementation bug out if the handles on the map (rather than just the sounds on the map) exceeds 8191?

Yes, I suppose I should apply that MAX_SIZE array size to all arrays using that storage method. You can always increase the MAX_SIZE variable to something like 500000 if you can't keep handle count down, it just slows down because of big arrays. It should still run perfectly fine, though.

Originally Posted by Captain Griffen

As to for local blocks, putting it in local blocks would be fine for running, but in combination with releasing when done, you'll run into issues, won't you? Since you may later on get new sound being created on some systems but not others, due to different numbers of sounds release / in the stack.

You'd use NewSound and ReleaseSound outside of the local block, all that'd be used inside it would be RunSound, which should be fine.

[Captain Griffen]

Originally Posted by Rising_Dusk

Yes, I suppose I should apply that MAX_SIZE array size to all arrays using that storage method. You can always increase the MAX_SIZE variable to something like 500000 if you can't keep handle count down, it just slows down because of big arrays. It should still run perfectly fine, though.

I'd say that's excessive when you could, for a far smaller performance hit, make it use a hash to between 1 and 8191.

You'd use NewSound and ReleaseSound outside of the local block, all that'd be used inside it would be RunSound, which should be fine.

Yea, but you might want to make a RecycleSoundWhenDoneForPlayer.

[Rising_Dusk]

Originally Posted by Captain Griffen

I'd say that's excessive when you could, for a far smaller performance hit, make it use a hash to between 1 and 8191.

Hrm, that's probably true. What hash would you recommend?

Originally Posted by Captain Griffen

Yea, but you might want to make a RecycleSoundWhenDoneForPlayer.

Huh, why? You can just RecycleSoundWhenDone() a sound that is only played locally and it will recycle it happily properly whenever.

[Pyrogasm]

Anyone else find it ironic that the guy who develops a Sound library is the one who is constantly reminding everyone that his computer doesn't have sound enabled?

:P


Noice library.

[Mr.Malte]

Quote:
Originally Posted by Captain Griffen
I'd say that's excessive when you could, for a far smaller performance hit, make it use a hash to between 1 and 8191.
Hrm, that's probably true. What hash would you recommend?
Quote:


Thats a nice idea, since the hash is just used internally, you'd not even have index conflicts.

[ToukoAozaki]

Actually I had plans to make exactly the same thing. (even interfaces are 98% similar, but whatever.) I threw it away due to hassles making the library neat. One of such hassle is locally played sounds when it comes to recycling.

The most correct way of recycling should be making sure whether the sound is still in use. The problem here is that you are not going to know whether a sound is idle if it is played in local fashion, unless you apply some dirty synchronization tricks. Once the stack becomes to have different number of sounds, trying to get the sound will desync when the stack is empty for some players but not to the others. This is because creating sounds desync whatsoever.

In your code, I see you utilizing timers to circumvent this fuss. It might be an alternative, but it has weaknesses. First, timers don't work quite well with sounds. For instance, the sound will continue playing when the game is paused, while the timer won't. Also, the sound durations are real-time, while timer depends on the game speed. This means the sound will cut off prematurely.

To fix the problem, you should try getting the approximate factor that each game speed poses to the game time. OTOH, game being paused can be a non-issue, since it would only make the sound unusuable for some extra time.

[Captain Griffen]

Originally Posted by Rising_Dusk

Hrm, that's probably true. What hash would you recommend?

H2I - H2I / 8191 * 8191 (+1 to avoid 0 and maybe 8190?), then loop to see if it's already being used.

Huh, why? You can just RecycleSoundWhenDone() a sound that is only played locally and it will recycle it happily properly whenever.

So when does it recycle? If it's dependant upon when the sound finishes, and it's only played in local block, then you'll have a problem.

[Rising_Dusk]

Originally Posted by Captain Griffen

H2I - H2I / 8191 * 8191 (+1 to avoid 0 and maybe 8190?), then loop to see if it's already being used.

And make it O(n) with that loop? I guess speed doesn't matter, but Vex has got me not liking that in principle. I dunno, if TimerUtils red can get away with an H2I-MIN_HANDLE_ID approach, I don't think it's a problem. I do see your point here, though, but I'm just not sure..

Originally Posted by Captain Griffen

So when does it recycle?

It runs a timer to circumvent the problem with recycling local sounds, since the stack needs to be synchronized for all players. Basically, it always recycles after the sound's defined duration regardless if the sound is played for a certain player or not. This keeps it consistent and keeps the stack happy. (Which I deemed a priority)

Originally Posted by ToukoAozaki

In your code, I see you utilizing timers to circumvent this fuss. It might be an alternative, but it has weaknesses. First, timers don't work quite well with sounds. For instance, the sound will continue playing when the game is paused, while the timer won't. Also, the sound durations are real-time, while timer depends on the game speed. This means the sound will cut off prematurely.

To fix the problem, you should try getting the approximate factor that each game speed poses to the game time. OTOH, game being paused can be a non-issue, since it would only make the sound unusuable for some extra time.

Yes, I noticed that too. The most frustrating part is the difference when the game lags, because that causes some strange discontinuities as well. I found that the difference between game time and real time is only noticeable for sounds over 2 minutes long (this may be system-dependent, as my computer is relatively slow). In testing I didn't think it was that big of an issue, but if it's system-dependent then it's basically impossible to reliably fix.

[ToukoAozaki]

Originally Posted by Rising_Dusk

And make it O(n) with that loop? I guess speed doesn't matter, but Vex has got me not liking that in principle. I dunno, if TimerUtils red can get away with an H2I-MIN_HANDLE_ID approach, I don't think it's a problem. I do see your point here, though, but I'm just not sure..

That is O(n) only if hashing function returns a constant value, making hash collisions 100% of the time. The technique Griffen suggested is one of the hashtable techniques to deal with hash collisions. Basically you save a copy of the key object reference itself, and compare it with the stored value after lookup with the hash of the key. If the key doesn't match, then try checking the next object pointed by the entry. This is generally done with linked lists, but arrays will do fine if every object has assigned unique indices. This technique generally works like supposed O(1) on average. Having poor hash will make the performance closer to theoretical O(n) worse case though.

Originally Posted by Rising_Dusk

Yes, I noticed that too. The most frustrating part is the difference when the game lags, because that causes some strange discontinuities as well. I found that the difference between game time and real time is only noticeable for sounds over 2 minutes long (this may be system-dependent, as my computer is relatively slow). In testing I didn't think it was that big of an issue, but if it's system-dependent then it's basically impossible to reliably fix.

Just get an approximate factor and add the extra gap (like 15 percentage point). While added gap would make recycling a bit inefficient, but at least it would be bulletproof from unwanted bugs.