Frequently Asked Questions
This page is a collection questions that occur from time to time. If you have a specific problem, please post a question to the forum.
- 1 General
- 1.1 Can I use LWJGL in commercial projects?
- 1.2 I have a problem with LWJGL, how do I get help?
- 1.3 How can I load images and sounds with LWJGL?
- 1.4 Why does LWJGL use a static API as opposed to an Object Oriented one?
- 1.5 Does LWJGL support GLU the OpenGL Utility Library? and where do I find it?
- 1.6 LWJGL's API starts with GL11, GL12, GL13, etc, how can I use it without needing to add those to every OpenGL method?
- 1.7 Will LWJGL support OpenGL ES?
- 1.8 Whats up with all those ByteBuffers? Why not just use arrays?
- 2 Building LWJGL
- 3 Distributing LWJGL Applications
Can I use LWJGL in commercial projects?
LWJGL is distributed under a BSD license which allows you to do whatever you want, as long as you include the LWJGL license, and any components you use (OpenAL, Jinput, Slick-Util, etc).
I have a problem with LWJGL, how do I get help?
How can I load images and sounds with LWJGL?
Well there are a number of libraries out there to allow you do this and you could always write your own image and sound loaders. However currently the recommended way to load various texture and sound formats in LWJGL is to use the Slick-Util library (note different from Slick2D).
Its pretty easy to use, just download the package and have a look at the examples included in the source code on how to use it.
Why does LWJGL use a static API as opposed to an Object Oriented one?
Libraries like OpenGL, OpenCL and OpenAL are written in C and hence static in nature. As LWJGL is designed to be as simple and as close to the metal as possible its API is almost entirely static to allows it to match as closely as possible to them.
Does LWJGL support GLU the OpenGL Utility Library? and where do I find it?
Yes LWJGL does support GLU, its found in the following location:
You will also need to add lwjgl_util.jar to the classpath.
LWJGL's API starts with GL11, GL12, GL13, etc, how can I use it without needing to add those to every OpenGL method?
LWJGL's api is intentionally designed like that in order to allow you to easily target specific versions of OpenGL. However if you do want to code without the class name before the method, you can simply just use java's static import feature.
import static org.lwjgl.opengl.GL11.*;
adding the above will allow you to use all the methods in the GL11 class without adding the "GL11." part before the method name. You can safely statically import all of the LWJGL opengl classes that you need as there are not conflicting method names.
Will LWJGL support OpenGL ES?
Yes, support is in the works and will be added soon to LWJGL.
Whats up with all those ByteBuffers? Why not just use arrays?
Basically because it's the fastest way to transport data to the OpenGL layer from Java.
Fetching the latest code from Subversion and running the ANT build.xml should build the lwjgl project jar files in libs/ and the natives in the subdirectories windows, linux, macosx or solaris.
Distributing LWJGL Applications
What options do I have to distribute my LWJGL Application?
There are a number of technologies that you can use.
- Java Web Start is deployment technology created originally by Sun and is shipped and installed with all Oracle Java run times. It allows java to run a jnlp (xml) file and start your application. Where its setup correctly it can allow launching an external java application directly from a web browser.
- The Java Applet plugin can embed LWJGL Applets and run them directly in the browser. LWJGL comes with an AppletLoader that assists you to deploy the tricky parts of LWJGL like native files, etc. Alternatively you can use JNLP Applets to deploy LWJGL as an applet for you.
- The Getdown deployment system aims to provide a system for downloading and installing a collection of files on a user's machine and upgrading those files as needed. Though just any collection of files would do, Getdown is mainly intended for the distribution and maintenance of the collection of files that make up an application. Its a Java Web Start alternative and used by some of the high profile LWJGL game companies like ThreeRings and OddLabs to distribute their games.
- LWJGL Application can also be distributed as standalone packages. A package will contain all the necessary jars and native files (also possible to include your own jvm with the package). The Java virtual machine is then started by telling it which jars to add to the class path, natives to the library path and the main class of your application. This is usually automated by a batch script or binary executable file. There are a number of tools available to automatically create an executable file for you such as Launch4J, JSmooth or Exe4J.
- Executable Jar - If Java is already installed correctly, java jars are executable when clicked. LWJGL uses native files and they need to be outside the jar before the jvm can use them (so you will need to create a mechanism that extracts them when executing the jar). Secondly you will have to set the location of the native libraries in your code before LWJGL tries to load them.
- Compiling LWJGL Application to native code. This method will compile your java code to native code and provide you a proper native executable binary (unlike the above tools which just wrap executables that work like a batch script and still use java). However there are many advantages and disadvantages to compiling java to native code. The two common tools to achieving this are the free GCJ compiler or the commercial Excelsior Jet application. Both can be made to work with LWJGL.
Can I use LWJGL with GCJ?
Yes. GCJ 4.0 and greater support LWJGL applications and are able to compile executables. Do note at the time of writing this the GCJ garbage collector is very weak and likely to cause performance problems. It is possible however to write java code in such a way that produces very little or no garbage at all in which case GCJ is pretty good.