Wc3C.net

Wc3C.net (http://www.wc3c.net/forums.php)
-   Scripts (http://www.wc3c.net/forumdisplay.php?f=737)
-   -   SoundUtils (http://www.wc3c.net/showthread.php?t=107433)

Rising_Dusk 08-30-2009 05:04 PM

SoundUtils
 
1 Attachment(s)
SoundUtils Library

Background:
This library's development spawned out of my need in a map to handle sounds easily. Sounds suck, through and through, and anyone that has attempted to work with them in the past will agree with me there. Just go do a search for threads relating to "Why doesn't my sound run?" This library removes a lot of the guesswork associated with handling sounds and simplifies their usage and troubleshooting tremendously.

Requirements:Code:
Expand Library:

Function List:
This library provides the following functions to the user.
  • function DefineSound takes string fileName, integer duration, boolean looping, boolean is3D returns integer
  • function DefineSoundEx takes string fileName, integer duration, boolean looping, boolean is3D, boolean stopwhenoutofrange, integer fadeInRate, integer fadeOutRate, string eaxSetting returns integer
  • function RunSound takes integer soundRef returns sound
  • function RunSoundOnUnit takes integer soundRef, unit whichUnit returns sound
  • function RunSoundAtPoint takes integer soundRef, real x, real y, real z returns sound
  • function RunSoundForPlayer takes integer soundRef, player p returns sound
  • function ReleaseSound takes sound s returns boolean
I remember first making this library, I had absolutely no idea how sounds work, and I wanted to make sure that no one else ever had this problem again. That was 8 hours of work that every mapmaker should be able to avoid with this library and (at most) a post in this topic.

I trust this will be useful to more than just myself!

darkwulfv 08-30-2009 05:08 PM

I've never found sounds all that hard to work with, honestly. You declare a sound variable in the Sound Editor and then use it later and destroy it when done. I don't see where the guesswork or problems come in. I've also never experienced the "first time doesn't play" bug either... Perhaps it's just me?

Rising_Dusk 08-30-2009 05:39 PM

Quote:

Originally Posted by darkwulfv
You declare a sound variable in the Sound Editor and then use it later and destroy it when done.

Ever try playing that sound twice within its own duration? You'll find that it doesn't work. That is the biggest limitation of the Sound Editor sounds and the main reason people look for better ways in the first place. Of course, I did explain that in this library's documentation... :)

uberfoop 08-30-2009 05:44 PM

Quote:

Originally Posted by darkwulfv
I've never found sounds all that hard to work with, honestly. You declare a sound variable in the Sound Editor and then use it later and destroy it when done. I don't see where the guesswork or problems come in.

The main point of this is avoiding the doesn't-play-when-two-instances-are-attempted issue.



I think it's pretty neat.

darkwulfv 08-30-2009 05:46 PM

Whenever I used sounds it was always a one-time deal (or the sound was repeated, but not at the same time).

After reading said documentation, I see this limitation now. I've just never experienced it.

Na_Dann_Ma_GoGo 08-30-2009 08:26 PM

I found myself in really heavy trouble regarding sounds, I may check this out.

Karawasa 08-30-2009 09:29 PM

I don't use sounds anymore but I remember back in Tropical Tag they were a huge pain in the ass. Thus, this seems like a useful library.

Anitarf 08-31-2009 12:11 AM

Are there any reasons to use ExecuteFunc in lieu of .execute?

Also, is there any advantage to recycling sounds other than the small performance boost of not creating and destroying handles?

Rising_Dusk 08-31-2009 12:39 AM

Quote:

Originally Posted by Anitarf
Are there any reasons to use ExecuteFunc in lieu of .execute?

Force of habit. If it's a problem, I can change it. They're the same, though, as far as I am aware.
Quote:

Originally Posted by Anitarf
Also, is there any advantage to recycling sounds other than the small performance boost of not creating and destroying handles?

You need multiple sounds to play multiple at a time and they're easy to recycle (and saves you from having to change their settings many times, since they remember their settings), so I figured might as well. You could consistently create new sounds if you wanted, but I figure that if you can recycle them easily, why not?

Anitarf 08-31-2009 12:59 AM

Quote:

Originally Posted by Rising_Dusk
Force of habit. If it's a problem, I can change it. They're the same, though, as far as I am aware.

.execute is supposedly faster.

Quote:

You need multiple sounds to play multiple at a time and they're easy to recycle (and saves you from having to change their settings many times, since they remember their settings), so I figured might as well. You could consistently create new sounds if you wanted, but I figure that if you can recycle them easily, why not?
If you don't know which sound particular is getting recycled, remembering their settings can be a problem. If you always play sounds at their default volume except in rare cases when you modify the volume, then once one of those rare cases gets recycled for a normal case, it's volume would no longer be at the expected default value.

Recycling can be a bigger performance hit than creating/destroying, in your case you need to maintain a stack for each sound type, plus the extra timerutils operations for the RecycleSoundWhenDone feature. Also to consider is the fact that other recycling systems like Timer/GroupUtils exist primarily because of bugs associated with destroying those handles, performance is a secondary concern.

Bobo_The_Kodo 08-31-2009 01:46 AM

.execute uses TriggerExecute rather than ExecuteFunc, and TriggerExecute is faster

Rising_Dusk 08-31-2009 02:05 AM

Quote:

Originally Posted by Anitarf
If you don't know which sound particular is getting recycled, remembering their settings can be a problem. If you always play sounds at their default volume except in rare cases when you modify the volume, then once one of those rare cases gets recycled for a normal case, it's volume would no longer be at the expected default value.

You could always just do call SetSoundVolume(MySound, 127) if you're doing something weird like that.
Quote:

Originally Posted by Anitarf
Recycling can be a bigger performance hit than creating/destroying, in your case you need to maintain a stack for each sound type, plus the extra timerutils operations for the RecycleSoundWhenDone feature. Also to consider is the fact that other recycling systems like Timer/GroupUtils exist primarily because of bugs associated with destroying those handles, performance is a secondary concern.

I can't really argue with this. I guess it's just a matter of preference. I prefer to keep my handle count low, and since I will never use more than 5 or so sounds at once, performance is a non-issue. The contrast here is that you'd need to run 9 additional natives for each sound you create as opposed to those you recycle. Does that rival the array handling of the stack? Heck if I know, but what I do know is that either way the difference is going to be negligible in all applicable cases.

Bobo_The_Kodo 08-31-2009 06:17 AM

RecycleSoundWhenDone_Child doesn't recycle the timer >.<

Rising_Dusk 08-31-2009 06:56 AM

Lol, I win.

Anachron 08-31-2009 12:30 PM

You should add an option what player to play the sound to, else this is pretty damn a waste of space in most maps.


All times are GMT. The time now is 11:25 PM.

Powered by vBulletin (Copyright ©2000 - 2020, Jelsoft Enterprises Ltd).
Hosted by www.OICcam.com
IT Support and Services provided by Executive IT Services