ID:260777
 
In the ever so popular Game Maker, it is very easy to use 3D sounds. In BYOND, it is not.

Not only do you need to perform the calculations for the sounds yourself, a major issue resides in the fact that sounds that last long won't automatically become louder or softer the closer or farther you get from them, as they should.

In Game Maker, it's easy enough to produce 3D sounds which get louder/softer as your distance from the target changes. In DM, not as such.

Would it be possible to create a "source" variable for the /sound datum that determines which atom the sound came from on the map? The client could track the source and adjust the settings based on the distance from the source.

The only problem that would remain is the manual specification of x/y/z & echo variables; they wouldn't be accurate anymore, so there needs to be a way to tell the client how it should calculate them (maybe implement this but start out with presets for different perspectives?)
This would be a super special awesome feature to have. I was thinking about delving into sound myself, but found it too tedius to care. I would definitely work with sound in my projects if it were easier/better to use.
Third'd.

Maybe the x, y, and z sound variables could act as an offset when the sound is attached to a location.
Android Data wrote:
In the ever so popular Game Maker, it is very easy to use 3D sounds. In BYOND, it is not.

Not only do you need to perform the calculations for the sounds yourself, a major issue resides in the fact that sounds that last long won't automatically become louder or softer the closer or farther you get from them, as they should.

A more accurate comparison would be to say that there are different ways of using 3D sounds that each platform has its own strengths and weaknesses with. In BYOND sounds are not tied to atoms and never have been, so the concept of a sound that changes position relative to the listener is a foreign one. The BYOND system however is more flexible for not having a location tie-in.

Whether sounds "should" be tied to locations as you suggest is a distinction best left to the game author. For those who want this, I don't see why it would be impossible or even that difficult to write a library to account for it.

Would it be possible to create a "source" variable for the /sound datum that determines which atom the sound came from on the map? The client could track the source and adjust the settings based on the distance from the source.

Perhaps, but such a system would likely introduce more complexities than it would solve. How would z-level differences be handled? Pixel offsets? What about separate rooms on the same z level that don't touch, like the insides of bulidings in an RPG? What about obstructions? Should doppler effects be handled? And most importantly, what translation would be best for mapping a given 2D game onto 3D coordinates? (One of my articles delves into several possible coordinate systems. While I'm happy with my preferred solution, there is no one-size-fits-all ideal.)

I'm not saying this can't or shouldn't be done of course, just that it's not going to be important for most games--particularly since most sound effects are one-shot events that don't last very long. And different games will have different concepts of how the sounds should be positioned relative to the listener. Given the many differences between game types and how sounds might be used in this way, I think this would be beter off handled by a library.

Lummox JR
In response to Lummox JR
Lummox JR wrote:
Whether sounds "should" be tied to locations as you suggest is a distinction best left to the game author. For those who want this, I don't see why it would be impossible or even that difficult to write a library to account for it.

All we need is some way to determine each sound's length so that we'll know when to quit tracking it and terminate it.
In response to Lummox JR
Lummox JR wrote:
For those who want this, I don't see why it would be impossible or even that difficult to write a library to account for it.

The difficulty in creating a library that I see is that there is significant network overhead involved.

You yourself have been against implementing a method to get the duration of a sound for the reasons I had, because of the network overhead involved: it would simply take too long for the client to receive the sound so it can actually do anything with it.

From what I can see, the same applies to 3D sounds: I feel the client has to do this since the client is able to do this nearly instantly, whereas the server has to add another CPU wasting loop to the mix for every single 3D sound I intend to play -- with 30 players the additional network traffic would not only be a waste of my bandwidth but also have too much of a delay to accurately relocate sounds, or so I think.

This suggestion is to get rid of the load of network traffic required to operate all of this. It's not the servers job to adjust 3D sounds. Heck, it's not the servers job to perform graphics processing, but I can live with that since the client is a thin client after all.

But surely it'd be possible to create a simple variable that the client can interpret to automatically adjust the sound? If you can't decide on a method, why not include all of them, and allow a second variable to be set to an integer representing which method to use?

You'd have a sound.source and a sound.source_method variable. The former would control where the sound came from and the client would track this. The latter would determine how to change the variables involved: change the x,y,z variables, is echo somehow a part of it, etc.

I fear that writing a library will be detrimental since the lag involved with sending these instructions would cause sounds to behave oddly.

And if you do think that it's feasible to just create a library for it instead of client-side processing being used, then I agree with Foomer: we need a way to determine how long we should continue to poll the sound for. Obtaining the length of the sound obviously isn't going to work due to the potential network traffic, but how about having the client send a message to the server when it has finished playing a sound?
In addition to this suggestion I would also like to suggest the ability to send a null sound to all channels except a specified channel in a single line, as opposed to sending 1023 network packets to do the same thing.