I need to throw away the current build.xml file because it absolutely won't work on OSX and many other platforms. What i need to find now is where the gcc command is defined that the build.xml keeps kicking off so I can edit it for OSX. I don't see it anywhere in the joal hive

Stuck. Once I can get past this - won't take long. Have tested out the new OSX OpenAL and its performance doesn't suck for a change

I've updated extal.c & extal.h from the latest version of the LWJGL (from which the original was taken) There have been a number of changes made to the files, especially around OSX, so it may be worth taking another look at getting it working. I don't currently have a Mac available or I'd try to figure it out myself. Hope this helps!

Great! I can't promise anything, since 1) I didn't write extal.c or extal.h, I merely borrowed them from LWJGL and 2) I haven't really done any development for OS X. That said, I figured it was worth mentioning that the files had been upgraded in the hopes that it will make a difference. Good luck!

I've gotten it to build. Haven't actually tried to do anything with it. I had to make some pretty significant changes to the build scripts in order to make it happen and for now I'm going to leave that as an excercise for the 'file merge specialists' to determine. I do know that the "isUnix" thing is problematic because OSX "isUnix" just as Linux is

Note that the runtests task will fail because the OpenALTest code is trying to open up the hardcoded DirectSound3D device. Don't know enough about OpenAL yet to fix that, but I'll take a look and report back tonight (this morning) if I find out what OSX expects.

I believe this is the culprit Naughty naughty piece of code... Clearly there is something here that wants a platform specific. Its evil because its buried fairly deeply in source code. After this I need to figure out that the native init method wants to do with it.

Hmm... Yeah, that would cause a problem. :-/ Basically, this should contain the name of the OpenAL shared library for the platform, it's needed by extal.c to dynamically load OpenAL in to the environment. I've been meaning to look into a more graceful way of dealing with this. In the meantime, you should be able to specify the name of the shared object (my guess is that it'll be similar to the linux entry, but don't quote me on that) for OS X and let the native code take it from there.

Unfortunately there is no such animal in OSX outside of frameworks. A framework is a shared bundle of libraries and respective resources on OSX. The mechanism for loading function pointers from it is a tad different though.

I'll table this for now because this is going to become a reasonably substantial change to the way the LWJGL code works - which is why I never ported their OpenAL code in the first place. They made a lot of assumptions about how things should work which just fall apart on OSX.

You probably want to take a look at LoadOpenAL() in extal.c since this is where the OpenAL libraries actually get loaded. (and where that exception is thrown)

Yeah, that's what I'm looking at now and now I remember why I didn't port OpenAL for LWJGL. To use the approach that they've chosen would require revamping the OpenAL framework such that its compiled into a shared library - which is not how its distributed.

I was hopeful, since IIRC they've apparently gotten AF running on OS X. As I noted earlier my mac dev experience is next to nil (what little native development I *have* done for the mac was almost 10 years ago, so I doubt very much of it applies today!)

Never a waste of time. What would become necessary is a change to the build of OpenAL and some changes to JOAL. The biggie is to patch ALFactory.java so that it at least does the init call which it doesn't now (and if this is from their current codebase I'm not sure how they're playing sounds witout calling init).

After recompiling OpenAL into a shared library and taking on the distribution responsibility for that (because it doesn't come that way from creative), then we can use the methodology that they're using. Its not the ideal way of doing things however.

Yeah, that's what I'm looking at now and now I remember why I didn't port OpenAL for LWJGL. To use the approach that they've chosen would require revamping the OpenAL framework such that its compiled into a shared library - which is not how its distributed.

Is the answer to have the OS X version just import the OpenAL headers directly? (instead of extal.h) There are a few other calls you'd have to ifdef out (mostly the load and initialize calls), but otherwise it should work. It's not the prettiest solution, but it might at least get us up and running.

Never a waste of time. What would become necessary is a change to the build of OpenAL and some changes to JOAL. The biggie is to patch ALFactory.java so that it at least does the init call which it doesn't now (and if this is from their current codebase I'm not sure how they're playing sounds witout calling init).

Well, I have to admit ALFactory is mine. It's just the calls it's making are theirs.

Quote

After recompiling OpenAL into a shared library and taking on the distribution responsibility for that (because it doesn't come that way from creative), then we can use the methodology that they're using. Its not the ideal way of doing things however.

While not ideal, it's also not a showstopper if it means getting something up and running in the near-term.

EDIT: Of course the question is just how much work rebuilding OpenAL as a shared library is going to be. Once again, my OS X ignorance is showing...

Okay, I will update CVS. I've got it working properly. Had to make a couple of changes for OSX specifics. Will work with the OpenAL.framework that you can download from Creative and will work with Garin to make sure that version is up-to-date.

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