Add -Djava.library.path=<directory where the lwjgl.dll is> to your commandline. Or simply ensure that the lwjgl.dll is in the current working directory when you fire up a jar, say. Don't forget to put OpenAL32.dll in there as well if you're doing sound.

Oh crap. Well, problem is, I read a post explaining the changes (i think it was acually from you) and I for whatever reason just assumed that was a complete change and it was the ONLY thing I had to do. My bad.

Just thought I would note that you can also drop the dlls into <path to jdk>\jre\bin or your windows system directory and any code you write will be able to find it. This allows you to skip the -Djava.library.path and/or copying the dlls from one project to the next.

Of course, you'll still have to be aware of what to do with the dlls when you redistribute, in which case simply keeping them in the same directory as the jar file is probably preferable to dropping them into a system directory.

I strongly advise not doing this though, as you'll be in for a world of pain and incompatibility. Just plonk the dlls in the same place as your current project and use the -D. It'll save you grief later, when we break the API

We're already in a world of pain and incompatibility when you break the API. What's one more step of copying the dlls?

I guess I don't mind replacing the entire lib system wide like this since it's exactly what I have to do in Linux anyway. There's no "just drop the .so into the same directory as the jar" there yet. (And I strongly hope the emphasis there is on the yet.)

In order to have a jar file do something when you double-click it, you have to set the "Main-class" property in the manifest. Now, I'm not sure how eclipse builds jar files, I usually do mine by hand or use Ant. Anyway, here's a little reference on what I'm talking about:

For distribution, you should create a zip file with a packing list simialr to this:

myjar.jarlwjgl.jarlwjgl.dllopenal.dll

That way when they unzip it, they can simply double click on myjar.jar. The Shooter example over on the GAGE homepage uses this. You could even pack your program into an NSIS installer and have it automatically generate start menu icons to your JAR file. Just make sure you set the working directory right or it won't be able to find lwjgl.jar.

Sorry if I break out laughing at some point, but I think you need to stop using Eclipse to make JAR files. I got the file through email and proceded to attempt running it. As expected, it didn't run. So I'm thinking "I'll check out what's in the manifest". I do "jar -xvf Test2D.jar META-INF" and open the META-INF/MANIFEST.MF. Man was I in for a shock. It was blank! I do a double take and then type "jar -tvf Test2D.jar". This is what I see:

Hmm... That's not right. The manifest was included as a normal file. Here's what you need to do to make this work:

1. Open a command line window2. Go to the directory with your files3. Type "jar -cvmf Manifest.mf Test2D.jar Test2D.class nehe.png"

This will tell the "jar" command to "[c]reate" a new JAR, be "[v}erbose" about what's going on, use the "[m]anifest" Manifest.mf, and operate on the jar "[f]ile" named Test2D.jar. All other parameters are the files to pack. Note that the order of the parameters matter. If you specify "-cvmf" you must then have "Manifest.mf Test2D.jar". If you instead specify "-cvfm", you must then have "Test2D.jar Manifest.mf". There you go. That should solve your headaches.

It never ends. Now it can't find my frickin .png. (->javax.imageio.IIOException: Can't read input file!)Excuse me while I do perforate my chest with a fork. I'm sure I can figure that one out though, god knows I need to do something for myself at least once today.

At least the manifest works. I'm gonna have rediculous batch files full of command line operations just like when I use to code with TextPad! woo! Thinking back, that's probably where my hatred comes from.

In hindsight I should have prolly just done what you said origionally, especially since you were trying to help me, but I made the mistake of trusting someone elses software.

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