@normen said:
The patch would be easier to read if it didn't have your non-jme code formatting changes included.. Anyway, the code binds completely independent code to the audio renderer and uses it in an extended AudioSource (namely AudioNode). You could just as well have your own instance of the listener and extend AudioNode yourself. Its the old problem again, trying to cram your stuff into the library code.
Like I said, the audio renderer needs to expose its listener publicly via a getListener() method in order to make things work.
As for the submitted patch, the relevant changes can easily be distinguished from the noise that was generated by the formatter.
And, if you suggest that I should provide an alternative Listener and thus reimplement the Application/SimpleApplication, then I might as well just fork the whole shebang and do it my way.
@t0neg0d said:
Global volume control is game specific... granted, most games provide the option, but it is still outside the scope of the engine itself. Instead of a patch, why not submit your control as a proposed addin, like BetterCharacterControl is not a physics specific... it's game specific... even more so, it's games with upright character specific. So, perhaps sumbitting the Control instead of a patch might be a better approach?
A custom control is not an option as it is not efficient enough. Especially when one could have it all implemented directly in the framework and also in a backwards compatible way.
@axnsoftware said:
Like I said, the audio renderer needs to expose its listener publicly via a getListener() method in order to make things work.
No, it doesn't need to do that. As I said, you set the volume at some point, why go in and get it again from the renderer? Thats the reason you "need to get it from there", because you misuse the library as your data storage again.
Its as if you display an image on screen and to get the image data next time you try and grab every pixel back from the GPU instead of just storing the image link when you send it to the GPU. Do you see what I am trying to explain?
@axnsoftware said:
As for the submitted patch, the relevant changes can easily be distinguished from the noise that was generated by the formatter.
Uh-huh. If you say so. I didn't think it was that easy to see the relevant code. Maybe because I didn't write it.
@axnsoftware said:
And, if you suggest that I should provide an alternative Listener and thus reimplement the Application/SimpleApplication, then I might as well just fork the whole shebang and do it my way.
No, I suggest (for a long time now) that you make your own classes that manage the audio as you want it instead of trying to change the library. I mean what would you do if you had vanilla OpenAL? Complain that they have no OOP layer? It would surely be more practical for the app you write..
Note I am not trying to make fun of you or anything but you seem to run into the same wall over and over again…