Hmm, this is somewhat a touchy subject that I have been avoiding with a 10 foot pole... but now that you've brought it out in broad daylight I have to respond.
Short history of fmod bindings for Java follows.
The first time I saw an fmod binding was when I stumpled upon NativeFmod, unfortunately its license is lgpl, which is incompatible with lwjgl, and has some undecided issues with java. To make matters worse, it was generated using swig, which I really loathe,
I therefore started the fmod binding for lwjgl, and got it working quite fast (IMO) on win32. Added linux support a bit later and everything was good. When I looked at Mac support there were some "huge" issues, coz unlike linux and win32, fmod was statically compiled. Being a bit clueless about how to fix it, I stalled on mac.
Some time after (cant recall if it was a short time or long time) aNt mentioned that he was doing an fmod binding too. At first I was a bit puzzled that they didn't use the lwjgl binding as a basis for the work. But he mentioned something about having bought a license, and somehow I (apparently) mixed all of this up, and mistook this as "having bought a license for java" - so that everybody could use his specific fmod binding for java, regardless of platform, for free. This was about November/December last year I think.
While he worked on this, I didn't touch any fmod at all, coz I wanted to evaluate what he came up with, and probably use his binding. It did indeed sound better than what I had come up with, and I know they were going to or had fixed some of the issues that lwjgl has with callbacks (which is pretty tricky). It was also OO, which despite the original api, I still like.
Fast forward some months (it took a while for the binding to materialize, due to vacation, sickness and licensing issues (I seem to remember)). aNt posts a release version.
I took it for a testdrive using supplied demoes and webstart. Everything seemed to work like a charm! However upon further inspection, I was a bit shocked at the sheer size of the binaries produced, and the whole framework build around the binding, to make it port easier. It felt like swig in disguise.
At this point I was faced between the following solutions:
- NativeFmod (Cons: Swig, lgpl)
- Fmod4Java (Cons: huge, anti-kiss)
- LWJGL-fmod (Cons: incomplete, missing mac support)
When narrowing it down, I deemed that the incomplete part was probably valid for all implementations - so I was basically left with getting Mac support going and lwjgl-fmod would be "done".
From *my* point of view, it seemed a lot more beneficial to complete the lwjgl-fmod binding than to swap over and use one of the other bindings.
Make no mistake however, when aNt announced to me that he was working on a "licensed" fmod port - I was ready to swap over, and use that for lwjgl. I do prefer to use others work, rather than haveing to reinvent the weel. Alas, I was disapointed with the result of fmod4java.
So back to getting fmod to work on Mac. Talking a bit back and forth with Elias, we got to a solution that basically meant faking dynamic loading on Mac, and it worked brilliantly!
We have an fmod binding (with some unimplemented stuff (5 or so methods, give or take) and some issues that I am aware of, yet none have come across
) that works on all three platforms. Unfortunately the mac version was completed just *after* the 0.96, but will make it into 0.97.
phew - that pretty much sums it up. Since I am not credited with a particular good long term memory, I might be slightly inaccurate in my summary of events.