I've been looking for something like OgreAL for a while -- especially something extensible/portable/open-source such as a libary which uses OpenAL, but which wouldn't be a nightmare to plug into Ogre3D.
However, I have a couple of questions if you wouldn't mind?
1 -- Since you're using the OpenAL SDK, does that mean that Creative's licensing applies? It looks as though their licensing requires you to arrange a distribution license with them if you develop a commercial application using their OpenAL SDK. Is that correct, and does that pose a problem for anyone else, or only me?
2 -- I am trying to keep my project as portable as possible. Since we may be using PhysX it already looks like we might be limiting ourselves to Windows. I was just wondering, in case we manage to avoid that, whether this version of OpenAL will also be limiting? I ask this because the SDK is labelled 'OpenAL 1.1 SDK for Windows' -- but I assume that is actually just referring to the install, and the code, if built in an otherwise portable application, will run on Linux PCs/Macs?
Creative's license would apply, but it's not that complicated once you break it down. OpenAL and PhysX both have Linux and Mac versions so you wouldn't be limiting yourself by using either one of these.
Well, I'm thinking about this part of the license as on http://developer.creative.com/articles/
... DK.exe&l=1 :
Creative grants to Licensee a non-exclusive, non-transferable, limited, royalty-free license to use the Software solely in accordance with the terms contained in this Agreement provided that:
* a. Licensee shall use the Software solely for the purpose of developing Licensee applications compatible with Creativeâ€™s products, unless otherwise agreed to by further written agreement from Creative.
* b. the Software is not distributed without execution of a separate distribution agreement between Creative and Licensee;
* c. the Software may NOT be modified except for the source code examples found under the â€œSamplesâ€
You're not distributing their code, their libraries need to be installed on the user's system, your are simply interfacing with their API. This is why I tell people to go install OpenAL on their own instead of packaging it up with OgreAL.
OK, that's great -- could you please tell me what parts of the OpenAL available on OpenAL's site (rather than the Creative SDK) I need to compile + .dlls etc. in order to permit OgreAL to work? I got the HEAD from subversion a couple of days ago, which came with the directories: alut, alutdll, contrib, demos, docs, include, OpenAL-MacOSX, OpenAL-Sample, OpenAL-Windows. I'm assuming I'd need to build the different versions to make my game playable on Mac or Windows? What about Linux in this context?
I'd really like to do this, but as far away from Creative as possible. Thanks : )
You would need to build OgreAL and your app under those different systems, you would need to rely on the user to either have, or install OpenAL on his or her system. Think of OpenAL like OpenGL or DirectX, you generally don't distribute OpenGL or DirectX with your application, you just rely on the fact that the user either has it already or can install it. You may package the dll's into a windows installer, but that's a different kind of thing.
OK, but I mean, specifically, can I just put, if I were building on Windows, the OpenAl src and include files from "/OpenAL-Windows" into my project, include them, and then, uh, which DLLs would I need to link to + do I need any .lib / .a files for linking in order to get OgreAL to work? I'm assuming OgreAL just needs Ogre and that part of OpenAL (e.g. _not_ ALUT?) to compile. I'm building on Code::Blocks with GCC, by the way.
And: I guess, since I never actually installed OpenGL either (and no one really does, do they?) the reason that OpenGL runs on my system when I use Ogre is because Ogre comes with an OpenGL DLL. And presumably I can bundle OpenAL in the same way. But if I don't use the SDK, will I need to build the/those DLL(s) myself? And can I build that/those in Code::Blocks without going quite mad? I'm a total novice at touching DLLs from the sourcecode side... Especially if the source isn't easy to build with non-VCC compilers.