Getting Started
The information below will let you know what to get and how to get it. However, the first challenge with any new API is getting some idea of where to start code wise. Most users of Slick so far have found that starting by playing with the included test examples is a good place to start understanding how things hold together. To get the tests you can download the distribution (see below) and find the tests in the org.newdawn.slick.tests package.
Contents
Getting the Slick Distribution
The Slick distribution contains a complete set of source code, test resources and tools for the library. It also contains build scripts and tests for the API. This is useful both to get a feel for how to use Slick and for making modifications to the platform to enhance how you use it. The distribution package also contains all the libraries required for deployment as webstart and applet. The distribution is available as a ZIP from:
http://slick.ninjacave.com/slick.zip
Determining Your Build Version
The current Slick version is always displayed at the top of the website. To determine the version of your Slick JAR open it in a ZIP tool. At the root of the JAR you'll find a file named “version”. This file contains a property defining the version in the form:
build=75
Getting Slick via BitBucket
Slick's source code and resources are stored in a central git repository. You can browse this repository using the a web client. You can also get direct read only access to the Slick hg using the following hg repository URL:
https://bitbucket.org/kevglass/slick
Alternatively, you can browse the source tree using a web browser using the link above.
Slick development is currently closed to new developers, hence write access to the repository is not currently available. Patches and feature adds are accepted via the forums and the development is planned to open up to selected developers at a later date.
Building Against Slick
To build against Slick you require “slick.jar” in your build classpath. How this is setup varies from build environment to build environment. Refer to the documentation for your IDE to determine how this can be setup. It is also advisable to have the runtime dependencies in the build classpath while building. This will allow you to use direct access to LWJGL and other dependencies when it becomes necessary to get a finer level of control.
Runtime JARs and Libraries
When running your Slick game you need to include the libraries in the “lib” directory in your classpath. These support each of the facets of the Slick API. In addition the native libraries (DLLs on Windows, .so on Linux, jnilib on MacOSX) must be included in your native library search path.
If you are seeing errors including the term 'UnsatisifiedLinkError' when trying to run the demos or the application this always means that Java cannot find the native libraries.
On Windows the library path includes the current directory. So if you run from the location of the DLLs they should automatically be found. However, on other platforms and if you want to use the natives from a different location you must specify the following command line argument when running Java:
-Djava.library.path=<the directory in which the native libraries are placed>
This argument should be placed directly after the “Java” executable name on the command line. The value specified should be the fully qualified path to the directory containing your DLLs, .so or .jnilib files. The native libraries should not be in jars. There should be no spaces in the path to the location.
Please note that an unsatisfied linking error always indicates that the native libraries can not be found (for one reason or another). This does not relate to not being able to find JAR files which are specified separately in the classpath.
