Added alternative sound library Open Audio Library (OpenAL)

[Stuessy]

I've added OpenAL as an alternative sound library to the game. This is highly recommended by Paul Lamp the author of SoundSystem. The library is part of the Lightweight Java Game Library. I am really hoping that we will get a much smoother and better working sound.

The downside of the new library is, that it isn't really platform independent. It needs native libraries for every operating system (Windows, Linux, MacOS and Solaris are included). That's why I had to commit my .classpath also. I tried to exclude it from the repository with #847, but we came to the arrangement that we won't delete and ignore the file, as new users checking out the repository will then have to setup their IDE manually.

As a fall back the "old" Java Sound library is still included, so you shouldn't see or rather hear any difference in running the game when OpenAL could not be started. Because of this I think we should merge it in develop instead of a new feature branch. It needs a lot of testing to see if sound is better now.

(See also issue #452)

[Maescool]

+1

[master-lincoln]

Very nice, I just tried it and have a way better sound experience. In combination with #810 this also fixes the channel null error. And I don't know how it is when deploying this. Can the native things be in the jar? How to tell the right path for th current OS? If we can figure this out this definitely needs to be merged. (tested under Linux with oracle java 7)

[Maescool]

For now include in the jar, later we will put it in de appdir/bin, just like the sounds needs to be extracted (sound only takes 25mb)

[danielduner]

@Stuessy Awesome! Would it be possible to put everything in the classpath and use some Java-logic to only load the right version for the current OS?

@Maescool What do you mean by sounds needing to be extracted?

[master-lincoln]

@danielduner For the future we would like to extract the sounds from the jar. These don't get changed very often, so if we put them somewhere else, we could decrease the download size by 90% since sounds take the biggest part. EDIT Maybe this helps for exporting the binary parts

[Stuessy]

@danielduner Everything is possible. ;) But i don't think, that it will be an option for us (yet). We have to change the sources in either paulscode/SoundSystem or LWJGL for that. I don't think that this is a good idea, because then we have to maintain that stuff too.

[danielduner]

Possible solutions from StackOverflow: http://stackoverflow.com/questions/9039510/java-project-with-native-libraries-for-different-platforms.

You can create several .classpath files (.classpath_Windows, .classpath_Linux etc.) and then create symbolic link to required version (Win/Lin/Mac) named ".classpath" The problem will appear whan you want to change any entry inside any .classpath_XXXXXXX - then you will have to update other .classpath files.

Or:

Eclipse lacks the feature you want. So, you can do it from Java.

Instead of calling System.loadLibrary, call System.load. This requires you to write code to calculate the correct pathname based on the current platform. You'll need to use -D to pass a value in to say what the current platform is, or read it from a file.

This removes java.library.path from the equation.

If your JNI library has dependencies, you will also need to set PATH, LD_LIBRARY_PATH, or DYLD_LIBRARY_PATH. Unless you take the further step of looking at https://github.com/bimargulies/jni-origin-testbed. For Windows, however, the necessary machinations with the delay-loader aren't in there.

[Stuessy]

The first suggestion might work, although I do not understand it. On windows I can't create symbolic links as far as I know.

The second suggestion is no solution for us. As I mentioned already, we have to change (and then maintain!) other sources than CS's for that.

[danielduner]

Doesn't LWJGL manage to automatically be system-sensitive?

[Stuessy]

I do not know. Maybe it's just necessary for Eclipse. I'm just trying to get it work with the symbolic links you suggested. I've just learned that Eclipse is capable of doing this. But this needs a modified .project file, which is also in the repository.

[master-lincoln]

Please don't worry about eclipse now. We just need it to be working in deployment... Its ok to have the .classpath file point to to a wrong native lib. In eclipse the SoundPlayer will fall back to the old sound system. People could still change the native path in eclipse options. But when cloning this repo you can start hacking without the need to configure classpathes. We should also add the .classpath file to .gitignore (but not delete it)

[Stuessy]

We should also add the .classpath file to .gitignore (but not delete it)

But it won't be ignored by Git if it's still in the repo.

[master-lincoln]

Damn you are right...I thought tracked files could also be ignored for changes...so we may really need to remove this file. An alternative would be to make the developers care for not commiting their changed classpath. You just need to run git update-index --assume-unchanged .classpath once.

[Stuessy]

Perfect! That's just what I was looking for.

So shall i remove .classpath from my commit? Or should this be the template for other Eclipse developers?

[master-lincoln]

It's ok as a template...leave it in.

[Maescool]

We do have OS detection code.. can't that be used to detect what native is used?

[Maescool]

The .classpath refers to the windows native.. won't that give issues?

[Stuessy]

We do have OS detection code.. can't that be used to detect what native is used?

As I said. As far as I know we have to change the LWJGL sources for that.

The .classpath refers to the windows native.. won't that give issues?

Just for Linux users of course. ;)

[Maescool]

i saw minecraft also uses this system.. how do they handle it?

[danielduner]

Could you point me to where in the code that the native libraries are loaded?

For modern projects, Linux support is often a higher priority than Windows (and rightly so)

[Shephiroth]

sorry to bother, but, what about neatbeans?

[master-lincoln]

Let's not talk about the damn .classpath file. If we leave it this way sound won't work under non windows in eclipse if you don't adapt it. But if you are a developer you know how to configure that for your IDE or you will know how to find out.

We just need to handle detection for the deployed jar.

[danielduner]

@master-lincoln The easiest solution would be to build different jars for different platforms.

But if we can figure out how to load the library dynamically in Java, it will solve both problems. @Stuessy says that this is impossible without changing the sources, but I find it hard to believe that a widely-used Java library wouldn't have proper cross-platform support.

[Maescool]

@danielduner so, we have to read the documentation ;)

[Maescool]

i see this library will also help to fix fullscreen http://www.lwjgl.org/wiki/index.php?title=LWJGL_Basics_5_(Fullscreen)

[master-lincoln]

I think I found a solution here. It states, that it's impossible to load the native libs from a jar. Instead we could extract the relevant pieces (with easy OS detection) and copy them to the user directory where we already store levels and stuff. Then we can use the "magic" org.lwjgl.librarypath property (see here) Update JarSplice would automate this.

Or we would need to setup jenkins for each specific OS.

[Maescool]

http://www.lwjgl.org/wiki/index.php?title=Distributing_Your_LWJGL_Application this will fix it

[Maescool]

@master-lincoln we'll discuss it later on irc, now still at the office :)

[Stuessy]

Seems like I stirred up a hornets' nest here. ;) I'm at the airport right now, so I don't have too much time to read any documentation. I think I will have time tomorrow to read the links you provided here. Shall I change anything on my commit or will it be a new issue?

What is the main problem right now anyway? The proper way to create the JAR and where to put the native libraries right?

[master-lincoln]

What is the main problem right now anyway? The proper way to create the JAR and where to put the native libraries right?

Exactly. Also the fall back to java sound library is not working. So you get no sound if the native lib is not found. That's why I did not yet merge this. We could handle jar packaging later if we still have java sound running.

[Stuessy]

Also the fall back to java sound library is not working. So you get no sound if the native lib is not found.

Okay, good to know. Why did nobody mentioned that? I'll try to fix that as soon as possible, but not before tomorrow.

[master-lincoln]

One more minor comment: The native stuff should also be located under lib instead of res

[andrew-hardwick]

The easiest solution would be to build different jars for different platforms.

Why are we using java then?

[danielduner]

Why are we using java then?

I didn't say it was a good idea ;) That comment was also followed by a discussion about how to solve the problem properly.

[Stuessy]

The proper way to check if Java Sound works on your machine (according to the SoundPlayer manual) isn't working for Linux. I just dropped the verification and set the library type to Java Sound if OpenAL isn't possible. This is exactly the behavior like it was before. Now the fall back works for me on my Ubuntu machine.

I still don't understand why #810 isn't working for you. It works perfect on my Win and Ubuntu machines. It really makes no sense that it doesn't work. Very irritating.

P.S.

I'll try to fix that as soon as possible, but not before tomorrow.

I lied! Sorry. ;)

[master-lincoln]

Hehe...Good job! I'll merge this now as your award...

[danielduner]

If it wasn't obvious from before, I just want to say that I think it's awesome that you are working on this @Stuessy