Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (756)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  OpenAL and current LWJGL-based tools  (Read 3484 times)
0 Members and 1 Guest are viewing this topic.
Offline philfrei
« Posted 2016-09-12 07:38:28 »

I made a working endless, non-repeating campfire sf/x, and it runs on the OpenAL that comes with LWJGL 3. First get it to work, then improve it, right?

If I understand correctly, there are basically four "layers" that require handling for sound:
> device
   > context
      > source
         > buffers

I was puzzling out what should be handled automatically by the class and instance, and what should be provided by the programmer. I'm figuring, since the "source" is given a 3D location, maybe it should be accessible to the programmer (sometimes audio cues need to be moved around). Also, possibly the programmer may be organizing sources into various "contexts."

I'm thinking the cue instance should require the programmer to provide these values as arguments to the constructor. The constructor would then handle setting up the streaming buffers so that the game developer wouldn't ever have to deal with that level of detail, they would just start or stop the CampfireSFX.

But it seemed to me that this could be a lot to ask of the game developer, especially if they had signed up for a library to help shield them from managing these details.

So...I thought the thing to do would be to see how the various game engines handle "device" and "context" and "source". First look was at a Slick audio example and...full stop: it is using LWJGL 2, not 3.

A quick look at our JGO "OpenGL" forum shows the first entry as LWJGL 2.9.2.
Does Libgdx also still use 2.9.2?
Does JMonkeyEngine also still use 2.9.2?
If so, are there plans to migrate to 3?

It is not clear to me from the documentation what versions of LWJGL these engines are using. I guess I just need to go ahead and download them and see what I get...

music and music apps: http://adonax.com
Offline princec

« JGO Spiffy Duke »


Medals: 1030
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2016-09-12 08:09:34 »

Firstly game engines will generally never expose "device" or "context". So you can neatly sidestep thinking about that.

That leaves a game programmer the general concept of a "source" of sound, and in general you've got the following sorts of sounds in games:

1. Background music, streamed from a simple stream
2. Background ambient effects, streamed from a location in space
3. Foreground effects, one-shot or looped from a location in space
4. UI effects, one shot, no location

Cover those four cases and that's 99.99% of everyone's needs sorted.

Cas Smiley

Offline philfrei
« Reply #2 - Posted 2016-10-31 03:27:50 »

@princec  I don't know why I didn't your this reply until just now!

I was glad to learn that libgdx now uses lwjgl 3. I can't recall what post that was from.

Here is an example of what I was trying to think through:

I have an SF/X that could work for a torchlight mounted and burning on a castle wall. As there are many torches in a dungeon game, there would be reuse of the cue. Because of the way OpenAL is implemented, it would require polling and populating buffers associated with each Source object (annoying and something a game application programmer shouldn't have to bother with), and we'd have to have a Source for each torch location as the Source holds the data used for 3D panning and volume calculations.

The logic for whether a given torch is heard or not would be kind of similar to the code used to determine if it is visible or not. At the edge of "earshot" we'd set up and launch the buffer streaming for the sound. The code to do this should probably be just the flipping of a switch if within earshot.

So, the API I would provide for a TorchBurningSFX would include setting a location, and a switch to flip it on or off, and maybe some additional ways to extend or vary the quality of the sound (letting OpenAL handle the volume and panning as needed for the 3D).

Then, it would be up to the game programmer to do something like update the switch based on monitoring the distance, e.g., turn it off it more than 150 something away, turn it on if within 120 something away (am making up numbers). The gap (150-120 or whatever) would be to lessen the amount of overhead/thrashing that comes from dancing back and forth over edge case. But that sort of decision would be left to the application programmer.

Does this sound like a good plan?
I'd also provide a getSource() method for programmers wishing to directly work with the Source properties.

I'm working on some "weather" effects right now. Hope to get back to trying some sort of SF/X for OpenAL in the next few weeks.

music and music apps: http://adonax.com
Pages: [1]
  ignore  |  Print  
 
 

 
DesertCoockie (52 views)
2018-05-13 18:23:11

nelsongames (83 views)
2018-04-24 18:15:36

nelsongames (74 views)
2018-04-24 18:14:32

ivj94 (759 views)
2018-03-24 14:47:39

ivj94 (87 views)
2018-03-24 14:46:31

ivj94 (643 views)
2018-03-24 14:43:53

Solater (102 views)
2018-03-17 05:04:08

nelsongames (184 views)
2018-03-05 17:56:34

Gornova (426 views)
2018-03-02 22:15:33

buddyBro (1086 views)
2018-02-28 16:59:18
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!