Deploying with the LWJGL Applet Loader 4 - Polish and Tweaks
Polish and Tweaks - Part 4
This part cover some optional features of the AppletLoader and various tricks to improve the user experience.
The Cache System
The AppetLoader comes with its own caching system. Once a file is downloaded the last-modified information from the server is saved. When the AppletLoader is run again only files that have changed and have different last-modified times will be re-downloaded. This behaviour is enabled by default so you don't need to include a parameter to enable it. If for whatever reason you want to disable caching, you can do this by setting the al_cache parameter to false.
<param name="al_cache" value="false">
The default caching system will check the jars on the server for changes every time the applet is run. While this may be fine for most, it does require a short period of time to do this. There is another parameter available known as al_version. How this works is you specify a number (float or int), once the AppletLoader downloads files it will save this number and never re-downloads files or check for changes until this number changes. This method will speed up the startup time as it won't check each file for changes at start up and will instead just check the number and start the applet immediately.
<param name="al_version" value="0.1">
Sharing Applet Cache
As mentioned above the files that are downloaded by the AppletLoader are stored in a folder as named by the al_title parameter, to prevent tampering from other hosts this is put in a folder named after the domain it is run on, so if the applet is run from lwjgl.org and al_title is appletloader, it will be stored in a folder called <tempDirectory>/lwjgl.org/appletloader/. Now for whatever reason you might want to share this cache over multiple domains, so that it starts faster and that your applet doesn't need to be downloaded everytime its run from a different domain. For this you use the al_prepend_host parameter (by default its set to true, but if you set it to 'false'
<param name="al_prepend_host" value="false">
The domain folder won't be created and instead it will just be stored in <tempDirectory>/appletloader/. Do note though any domain may now store its cache in that folder if it has the same al_title value so be sure to make it unique. You shouldn't need to use this parameter unless you have a specific need for it.
For debugging there is the al_debug parameter this is simply there to help debug problems, it'll insert delays and slow down all the actions the AppletLoader does intentionally and provides extra debug information. This should be disabled for end users. By default it is set to false.
<param name="al_debug" value="false">
Hidden LWJGL Switches
LWJGL has a number of hidden switches that allow you to enable and disable various things. You can specify these in the AppletLoader using the lwjgl_arguments parameter.
<param name="lwjgl_arguments" value="-Dorg.lwjgl.input.Mouse.allowNegativeMouseCoords=true -Dorg.lwjgl.util.Debug=true -Dorg.lwjgl.opengl.Display.allowSoftwareOpenGL=true">
Give your applet tag an id (in html).
<applet code="org.lwjgl.util.applet.AppletLoader" id = "myApplet" archive="lwjgl_util_applet.jar" codebase="." width="640" height="480">
var appletloader = document.getElementById('myApplet'); var applet = appletloader.getApplet();
Once you have the applet object you can communicate with it as normal (e.g. calling applet.x() will call the public method called x() in the applet).
You can pass normal java applet parameters as usual, they'll be passed transparently to your LWJGL Applet through the AppletLoader.
Using Your Own Custom Natives
To use your own natives in addition to the LWJGL natives, you simply put them in the native jars and once the AppletLoader downloads them they will be extracted to a folder which will be added to the java.library.path, you can get this path by calling System.getProperty("java.library.path").
A bit of extra speed and compatibility
AWT on which the LWJGL native window sits, can sometimes initialise a hardware accelerated pipeline, this is undesirable as you want LWJGL to have maximum performance. Also on some weak graphics drivers using hardware acceleration on both LWJGL and the underlying AWT canvas is buggy and may cause issues. To disable all hardware acceleration on AWT you can use the following parameter. This will disable all directdraw, opengl, directx and other AWT settings.
<param name="java_arguments" value="-Dsun.java2d.noddraw=true -Dsun.awt.noerasebackground=true -Dsun.java2d.d3d=false -Dsun.java2d.opengl=false -Dsun.java2d.pmoffscreen=false">
Since the Java 1.6.0_10, applets have the ability to run in a separate process. It is highly recommended that you use this for heavy and powerful java applet like LWJGL applets. It will make your applet much more stable and compatible. This is enabled by using the following parameter:
<param name="separate_jvm" value="true">
Even Faster AppletLoader startup
The AppletLoader already starts really fast as its designed to be small and download quickly so it can display a loading screen as fast as possible. However, every time an applet starts java makes a connection to the server in order to check whether a new version of the jars in the archive tag are available. This can cause a delay for a few seconds before the applet starts. You can remove this delay by marking your jar with a version using the cache_archive_ex parameter. It works similar to how the al_version tag works, you set a version number to the jars found in the archive tag. This will stop java checking for updates every time the applet is run and only check if the version number changes. The format that this must be is [jar name];preload;[version], each jar you have in the archive tag is separated by a comma and the format of the version is x.x.x.x where each x is a hex number 0-F.
<param name="cache_archive_ex" value="lwjgl_util_applet.jar;preload;0.0.0.1, lzma.jar;preload;0.0.0.1">
There is also a magical parameter in the JRE known as codebase_lookup, when the applet classloader needs to load a class or resource, it first looks in the jars and then searched the applet codebase. A connection has to be made to search the codebase and this is a slow process. If your don't have any resources on the codebase (outside your jars) you should definitely use this parameter, it can do wonders for startup time and in some cases while running the applet. Use this by calling
<param name="codebase_lookup" value="false">
Polish and Tweaks - Part 4