Re: Two more questions
Eric Wing <[email protected]> Fri, 16 Nov 2012 15:32:09 -0800
| Newsgroups | gmane.comp.lib.openal |
|---|---|
| Message-ID | <CA+Q62MCdie1ckcuFsPtmCG+mGoenJFCjMjoiUYW+cpXddkhhFw@mail.gmail.com> |
On 11/16/12, Chris Robinson <[email protected]> wrote: > On 11/16/2012 01:26 PM, Jason Daly wrote: >> Just to clarify, you also separate contexts if you need multiple >> listeners, each with their own positions/orientations (this would be >> multiple different context states, as Chris referred to it above). This >> will be important if you're trying to render sound to each user from his >> or her own perspective. So, if Listener A is near a train and Listener >> B is farther away, the sounds from the train would be louder for >> Listener A than for Listener B. > > I honestly have difficulty thinking of a scenario where multiple > listeners on one ALCdevice would be useful. The most I could see is for > split screen, or picture-in-picture, or something like that. In most > other cases, you'd either share one listener or have a completely > separate device with its own context. > Actually, this has been one of my long time gripes with OpenAL. I need both multiple contexts and I need both of them to render sound simultaneously. It isn't a major use, but it comes up enough for me. I want multiple contexts (listeners) for several different scenarios: - Multiple views (your split screen example, or think of a 1st person flight combat with a radar view). For compartmentalized/modular development, trying to not trample over different module's state is a pain. - Menu views: very similar to the above; everything emanating from the menu is probably not spatialized. But the main view may still be going and playing sounds. Again, the menu person/team shouldn't have to worry about the game person/team screwing with the listener position or vice-versa. - Multiple simulations: The Corona SDK is the best example of this problem. In the Corona SDK, we allow users to write apps/games for iOS/Android in Lua. Our Mac/Windows simulator product allows them to run their code as a regular Mac/Windows program. The OpenAL system only allows us have one active context at a time so we can't run two different user app/simulations at the same time (there are use cases for this; imagine a multiplayer game). In fact, our main application window is written in our own product which is left open at all times by some users and provides links to documentation and our RSS feeds and is just another simulation. We had to make a special hack to disable audio it would never interfere with the user's audio. -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ _______________________________________________ Openal mailing list [email protected] http://opensource.creative.com/mailman/listinfo/openal