|Line 62:||Line 62:|
====Does LWJGL have a Maven Repository?====
====Does LWJGL have a Maven Repository?====
, see [[LWJGL use in Maven]].
Revision as of 12:48, 20 October 2011
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.
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 methods all start with the class name (e.g. GL11, GL13, etc), can I use it without adding 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.
Does LWJGL support OpenGL ES?
Yes, OpenGL ES is now part of LWJGL, however it is not built with the distributed binaries. You need to compile it yourself using the supplied ANT Build files.
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.
Does LWJGL have a Maven Repository?
LWJGL is in Maven Central starting with version 2.8.0, see LWJGL use in Maven.
What are all the Jars include in the LWJGL download bundle?
The LWJGL download package contains a number of jars, they are used for the following:
- lwjgl.jar - This contains the core of LWJGL and should be the only jar needed for a simple LWJGL application.
- lwjgl_util.jar - The jar contains utility classes that optionally maybe needed, these include the OpenGL GLU, various Vector and Matrix classes, MappedObjects, etc.
- lwjgl_debug.jar - This is the same as lwjgl.jar but will provide additional debug information. Do not load at the same time as lwjgl.jar as it contains identical classes.
- lwjgl_test.jar - This includes basic examples and demos for LWJGL (e.g. A Space Invaders Game).
- lwjgl_util_applet.jar - This jar contains the AppletLoader a utility used to deploy LWJGL in the browser.
- lzma.jar - This is an optional jar used with the AppletLoader (above jar) and is only needed if you are using lzma compressed jars.
- jinput.jar - This is the JInput jar and is needed if you intend to use game controllers with LWJGL (joysticks, joypads, multiple mice, etc). Not needed if you only intend to use a Keyboard and/or Mouse.
- asm.jar - This is an optional jar which contains the ASM library and only needed if you are using the MappedObjects found in the lwjgl-util.jar.
- asm-util.jar - This jar contains utilities for the ASM library and should only be needed when using the above asm.jar.
- AppleJavaExtensions.jar - This jar contains stubs for the mac and is only needed when compiling lwjgl on a non mac platform.
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.
- Java Applets can embed content inside a browser. Java Plugin2 added in java 1.6.0_10+ has support for deploying applets using JNLP files. Applets running with JNLP files can deploy and use LWJGL Applets in the browser.
- The LWJGL AppletLoader is a small deployment system that enables you to run LWJGL Applets. It automates all the tricky parts of using LWJGL as an applet (such as deploying natives, nice progrss bar, etc) while at the same time providing a friendly end user experience.
- Getdown is an alternative to Java Web Start and considered by many to be superior. GetDown is a deployment system which 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. It is 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 to create .exe files for windows or JarSplice to create a ShellScript for Linux.
- Installer Software - These are Installer/Setup programs that are executables themselves and will install applications on the system they are run on, some are cross-platform while others are designed for a specific platform. They usually guide users through the installation procedure with a set of dialogs and instruction screens. You can use these to create installers for LWJGL applications and if required also embedded the JRE with them. Some examples include NSIS, lzPack, InstallBuilder, etc. A full list of Installers can be found here.
- 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 the natives and sets the path to them in Java when your jar is executed. Tools like JarSplice will automate this process and create a single executable jar from all your jars and at the same time include the native files inside.
- 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.