LWJGL build with FMOD support

Started by Matzon, May 23, 2004, 17:22:35

Previous topic - Next topic

Matzon

We now have support for FMOD. This is an *alpha* release, and currently only win32 - waiting for linux builds to arrive (and be tested). The FMOD build will in a short time be supported on all platforms supported by LWJGL.

Binary & Source:
http://matzon.dk/brian/lwjgl/builds/lwjgl-2004-05-23-fmod.rar

This is the first shot at the binding, and it will most likely be refactored a bit (callbacks could change, haven't tested it properly yet, so I might change it some way).
Some methods aren't implemented, an exception will be thrown if called.

Please check out the org.lwjgl.test.fmod.* for how to use FMOD.
Playing an ogg vorbis/wave/mp3 file is as simple as:
java -cp lwjgl.jar;lwjgl_fmod.jar;lwjgl_test.jar; org.lwjgl.test.fmod.StreamPlayer <my music file>

Please not the actual FMOD dll is not distributed, and must be aquired from http://fmod.org
FMOD is only free for non commercial programs (and "cheap" for commercial programs). The actual LWJGL-FMOD binding, is ofcourse BSD licensed and free, like the rest of LWJGL.

Matzon

This is just a small post, to deflect any preemptive strikes against the FMOD binding.

Why FMOD, isn't OpenAL fine?
OpenAL excells as a 3d sound engine, but falls somewhat short as a general purpose music player. FMOD does both 3d and "regular" sound, and includes native support for mp3 and ogg vorbis (do note mp3 license issues).

Why make your own binding instead of the already released (http://topresult.tomato.co.uk/~jerome/NativeFmod/index.html)
Initially we were going to use it - and we therefore waited several weeks (if not months). When it finally was released, the license was incompatible and was made using SWIG (http://www.swig.org/). This resulted in a binding that was anything but nice to work with - totally contradictive of everything LWJGL stands for. Thus we made our own binding. A large part of the work, has actually been to embed the FMOD documentation as javadoc, so you have easy access to the FMOD documentation

Why is the FMOD binding supplied in it's own dll/jar?
A large portion of LWJGL developers/users, will not need the FMOD binding (they are content with the OpenAL binding), we therefore made it easy to seperate it from the main distribution, so that it doesn't become bloated.

Chman

Hey sounds great :)
I wa using OpenAL for sound and Audiere lib for music (which is very very fast), but I'm gonna take a look at your fmod binding...

What would you recommand ?
Using OpenAL for sound only and fmod for music only or simply use fmod for sound and music ?

Chman

Matzon

linux build:
http://matzon.dk/brian/lwjgl/builds/liblwjgl-fmod.zip
though elias had to change some stuff to get it to work, I am betting on the changes to be compatable.

QuoteWhat would you recommand?
Well, right *now* I would go with OpenAL, since the FMOD binding isn't finished ;). That said, down the line, FMOD seems to be more complete (and has tons of other features (CD Control, Recording, CDDA, samples, mp3/ogg vorbis out of the box, samples, modules etc)). However, since FMOD comes with a pricetag for commercial development, it might not be an option for everybody.

Chman

QuoteHowever, since FMOD comes with a pricetag for commercial development, it might not be an option for everybody.

That's the problem and that's why I think I'm gonna use OpenAL & Audiere...

oNyx

Good news I guess.

>That's the problem and that's why I think I'm gonna use OpenAL & Audiere..

250$ is too expensive for me, too. :?

princec

Hey, if you're gonna go pro, $250 is just a drop in the ocean...

Cas :)

Chman

You know I'm just a little 18 years old french guy, so $250 is about 230 euros, which is a lot for me :P
Even if I sell my game, I don't think I'll get famous and earn more than $250 :)

Anyways I'm sure this fmod binding will be useful for many free game developpers !

Chman

oNyx

>Hey, if you're gonna go pro, $250 is just a drop in the ocean...

Sure. But it's 50% of my monthly (beeing able to work fulltime on my game) burnrate and I need about 150â,¬ pretty soon now for setting up a "company" (it's cheaper anywere else in the EU, isn't it?).

Maybe for the 3rd game, wich is most likely that game, I dremt about doing for about a year now.

Well, I'll see... and it's always a good thing to have more tech choices (and I really like fmod - it's easy to use and damn fast).

Tora

Hi all! I'm new here :)

I was evaluating doing some games and demos with lwjgl, and THIS is just the only thing I was missing...  XM playback! :D

I'm very happy now  :)

Do you plan to implement the callback functions? For me is very useful, as they let me sync much accurately the video effects with the music.

You're doing a truly amazing and good work with lwjgl :) Thanks! :)

Tora

Hi again!

About the licence 'problem' about fmod, there are another alternative:

http://dumb.sourceforge.net/

But hasn't so many features as fmod, of course ;)

I agree that if you're doing something commercial, 250$ is something you could afford (as I've read in the fmod site, you'll get unlimited licences for your site, if you're a shareware developer).

If you're not going to develop commercial products, it's for free ;)  So there are possibilities for everybody.

Matzon

Quote from: "Tora"Do you plan to implement the callback functions? For me is very useful, as they let me sync much accurately the video effects with the music.
It's planned, and has the backend for it (well, most of it) - but there are still some issues... I'll be working some more on the fmod stuff later this week, including finishing and testing the callback stuff. However, I don't know *how* precise syncronization you can do, since in it's current form it:
1 - FMOD calls registered native method for callback
2 - native callback code calls the generic FMOD callback method as appropriate
3 - java code determines which object was registered to the specific stream/dspunit and calls the callback method on the correct object.

This is a bit slower than doing pure C code - especially the JNI bridge... Particularly dsp effects might have issues - but I am only guessing, I have no numbers whatsoever.

elias

Well I don't know how precise a sync you need, but I guess that anything < 1 ms is enough, and that is easily achievable for one call, even though it involves calling java from JNI and some reflection magic.

- elias

Tora

Anything less than 20ms is fine for me :)