You're best off checking out the project from Git, rather than using the bundled sourcecode in the release .zip and .tbz2 archives. If you do want to use the bundled source rather than checking out the project, you'll have to do some file copying: The build expects the LWJGL libraries and a few other Jar files in the "lib" directory. Specifically it's looking for: AppleJavaExtensions.jar (presumably just for OSX) jinput.jar lwjgl_test.jar lwjgl_util_applet.jar lwjgl_util.jar lwjgl.jar lzma.jar snakeyaml-1.9.jar log4j-1.2.16.jar ... Possibly some of those are optional, but you may as well leave them in. Inside lib/native, make sure that you've got the "native" LWJGL files, as well. These will be .dll if you're on Windows, and .so on Linux. Additionally, technically speaking you'd want to copy the "textures" directory over into the source tree as well. At that point, you should theoretically be good to go. You should be able to develop (or just use) the source either from the commandline or Eclipse. The tool was originally developed in Eclipse, but EGit (Eclipse's Git interface) turned out to be kind of annoying, which was all the urging I needed to abandon the crutch of handy autocompletion for the warm comforts of my beloved vim (which, yes, I know, can do autocompletes if you coerce it into doing so). COMMANDLINE ----------- If you're on the commandline, you can use Ant to build/run, etc. "ant run" should be sufficient to run the app (it will compile up a debug version automatically). "ant dist" will package it up as if you're doing a release, though note that right now that step will only work on Linux. I've never taken the time to figure out how to get launch4j to work on other platforms. See build.xml for other ant targets. ECLIPSE ------- First, a disclaimer: as I mentioned above, I haven't actually used Eclipse with this project in some time, so it's possible that you'll need to do more work than is mentioned here. I believe that these docs should be sufficient, but let me know if it's not. If you want to use Eclipse, there's a couple of extra steps. I feel that both of them really *should* have workarounds which would prevent them from being needed, but I never did figure it out. Anyway: 1) In Eclipse, go to Window -> Preferences -> Java -> Build Path -> Classpath Variables, then click the "New" button and create a variable called "XRAY_CLASSPATH". Point that directory at the "lib" dir underneath the X-Ray project. This should let you compile the app. (As an aside, the ".classpath" file distributed with the original X-Ray distribution specified its jar files with relative paths, such as "lib/lwjgl.jar". I could never get that to actually work, though, which is why they're all prefixed with that XRAY_CLASSPATH var now. It'd be nice to know why, and equally nice to be able to get rid of having to set up that variable.) 2) To actually RUN the app through Eclipse, right-click on the top project in Package Explorer, go to Properties -> Run/Debug Settings -> XRay, and click on "Edit". In the Arguments tab, set the VM arguments to: -Xms256m -Xmx1024m -Djava.library.path=/path/to/workspace/xray/lib/native -Dlog4j.configuration=file:support/log4j.properties ... replacing the "/path/to/workspace" with the path to your actual Eclipse workspace. If anyone's got a way around having to do that, let me know. You MIGHT have to go into the Classpath tab there, as well, and add in the JARs under lib/ again (which would show up under that XRAY_CLASSPATH var), though I don't remember if that automatically happens or not. The various build.xml targets should work fine inside Eclipse, too, of course.
agnes219