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