Just thought I'd share some experiences I've had with this. I've spent most of the night getting it to work, might save somebody a little time.
Ok first off, there's a lot of references in the appletloader.html to lwjgl.jar.lzwa or some weird names like that. Cant figure out why they suddenly use those, but they do.
You can safely delete these jars and replace them with the ordinary lwjgl jars, for example those from jme or some youve downloaded elsewhere. Also replace any reference to them in the applet tag with the ordinary lwjgl file names, then sign the jars only using your own signature. That also stops the applet from showing the signature warning twice.
If you want to package additional dlls (for physics, for example) you would have to rebuild a new jar, windows_natives.jar, linux_natives.jar etc, where you place the lwjgl dlls and the other dlls. Then sign the jars and
of course make a reference to them in the applet.
If you only target one OS, you only have to make references/nativejar to that… dont be afraid to remove the linux natives (and their reference in the appletloader.html of course), it will still work (but of course not on linux ).
Now comes the strange thing. You have done all this, still it only finds the lwjgl libs when running, not your physics libs (or whatever).
What you do is this, and it's a bit ugly but coudlnt get it to work any other way:
Second any native files in the native jars (windows_natives.jar, linux_natives.jar, etc) are extracted along with the lwjgl natives to the folder System.getProperty("org.lwjgl.librarypath"); so you'll have to load any additional native files from there.
Wasnt it what I said ? It wasnt mentioned in the docs,or anywhere else as far as I know, so how are people supposed to find out ?
The lzmafiles comfused me a bit.I just took a second look at them, and they are not really smaller than their .jar counterparts..
some are even bigger. So I think personally, that it's a bit annoying that they would use something like that, and not tell that its alright to use standard jars.
I mean I wanted to create and sign my own jars, but should I make them as lzma, sign those, and how do I do that etc ? Just alot of confusion and problems over nothing, and one have to spent a night figuring it out..which shouldnt be necessary.
The lzmafiles comfused me a bit.I just took a second look at them, and they are not really smaller than their .jar counterparts..
some are even bigger. So I think personally, that it's a bit annoying that they would use something like that, and not tell that its alright to use standard jars.
hmm, shouldn't really be the case that they are bigger, lwjgl.jar is about 500kb at maximum jar compression, while lwjgl.jar.pack.lzma is about 100kb.
anyway I'll see if I can clear out some of the confusion in all this for the LWJGL 2.6 release (which hopefully should be soon).
Oh and there's a detailed tutorial in the works covering almost all aspects of LWJGL applets and the AppletLoader, again should be out with/before the 2.6 release.
also the applet package has now been simplified, the standard jar and lzma/pack stuff has been separated and should help avoid confusion in the future.
Here's the appletloader.html after the changes I've made.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>AppletLoader</title>
</head>
<body>
<center>
<applet code="org.lwjgl.util.applet.AppletLoader" archive="lwjgl_util_applet.jar, lzma.jar" codebase="." width="900" height="600">
<!-- The following tags are mandatory C:UsersMikkelAppDataLocalTemplocalhostappletloadertest
-->
<!-- Name of Applet, will be used as name of directory it is saved in, and will uniquely identify it in cache -->
<param name="al_title" value="appletloadertest4">
<!-- Main Applet Class -->
<param name="al_main" value="net.ob3d.OB3DStandardApplet">
<!-- logo to paint while loading, will be centered -->
<param name="al_logo" value="appletlogo.png">
<!-- progressbar to paint while loading. Will be painted on top of logo, width clipped to percentage done -->
<param name="al_progressbar" value="appletprogress.gif">
<!-- List of Jars to add to classpath -->
<param name="al_jars" value="lwjgl_applet.jar, lwjgl.jar, jinput.jar, lwjgl_util.jar res.jar,onlineboxing3d.jar,physx4java.jar">
<!-- signed windows natives jar in a jar -->
<param name="al_windows" value="windows_natives.jar">
<!-- signed linux natives jar in a jar -->
<!-- signed mac osx natives jar in a jar -->
<!-- Tags under here are optional -->
<!-- Version of Applet, important otherwise applet won't be cached, version change will update applet, must be int or float -->
<param_ name="al_version" value="0.8">
<!-- whether to use cache - defaults to true -->
<!-- <param name="al_cache" value="true"> -->
<!-- background color to paint with, defaults to white -->
<!-- <param name="boxbgcolor" value="#000000"> -->
<!-- foreground color to paint with, defaults to black -->
<!-- <param name="boxfgcolor" value="#ffffff"> -->
<!-- whether to run in debug mode -->
<!-- <param name="al_debug" value="true"> -->
<!-- whether to prepend host to cache path - defaults to true -->
<!-- <param name="al_prepend_host" value="true"> -->
<!-- main applet specific params -->
<param name="test" value="org.lwjgl.test.opengl.awt.AWTGearsCanvas">
<p>
if <code>al_debug</code> is true the applet will load and extract resources with a delay, to be able to see the loader process.
</p>
<center>
</body>
</html>
Note this is only target for window, since I havent build the Physx libraries for Linux yet.
Thanks, I wondered what the al_version did. Changing it forces the applet with jars to reload instead of using cache ? And if it is not working, the only way to reload new jars is to change their names ?
al_version just assigns a version number to your cache, meaning that it will never check for updates until the version number changes (and always just use the cache, if available). Its just a way to get faster startup.
By default (al_cache is true) and it checks for changes at startup (may take a second or two, this is the delay al_version eliminates) and if a new version of the jars is available it will redownload the jars otherwise just use the cache version. Setting this to false means it will redownload new jars everytime its run.
So what your saying is that al_version dont work…and this tag is the only way for it to check for updates…so in fact, at present, it is not possible to update the applet unless you disable the cache which will make it update EVERY time ?
But if you rename the jars. to for exmaple lwjgl1.6.jar it will see that theres a new jar and download that despite the version number right ? and delete the old jars from the cache that are no longer referenced from the applet.html. Or will it simply just stick to the version, use those jars in the cache, and do nothing, no matter whats in the applet tag?
So what your saying is that al_version dont work..and this tag is the only way for it to check for updates..so in fact, at present, it is not possible to update the applet unless you disable the cache which will make it update EVERY time ?
excluding this tag won't disable the cache as al_cache is still enabled, which simply means that every time you start an applet, it will check for updates and only download the files that have changed.
Baune said:
But if you rename the jars. to for exmaple lwjgl1.6.jar it will see that theres a new jar and download that despite the version number right ? and delete the old jars from the cache that are no longer referenced from the applet.html. Or will it simply just stick to the version, use those jars in the cache, and do nothing, no matter whats in the applet tag?
having al_version enabled means it will simply stick to the number regardless of what jars are downloaded or not and will not check for further updates after it downloads once. As when you specify a number, its expected that you have everything you need, if you do change it, then just bump the number.
OK great so now it just works like a regular applet, where you, when you update a jar. have to change it's name if you want to be sure the client download and uses it. If al_version DID work, you would not need to change the jars name, simply change there al_version, and it would force a reload once more until version is changed again. Is that correct ? also, what in reality would give the same effect, as I understand, is to change the al_title version, which controls the cache dir…?
OK great so now it just works like a regular applet, where you, when you update a jar. have to change it's name if you want to be sure the client download and uses it.
also, what in reality would give the same effect, as I understand, is to change the al_title version, which controls the cache dir..?
yes it works like a regular applet, but you don't have to change the name (if you don't want to), the appletloader will read the LAST_MODIFIED time of the file from the server and automatically know if it needs to redownload it or not.
changing the al_title version will change the cache directory hence cause it to fully redownload again but this is not recommended, since it'll leave lots of unused cache directories on the users computer.
Baune said:
If al_version DID work, you would not need to change the jars name, simply change there al_version, and it would force a reload once more until version is changed again. Is that correct ?
yes. (again as mentioned above, you don't need to change the jar name for it to redownload).
pushing really hard to get all the quirks out for the LWJGL 2.6 release, think we've got almost everything now (at least in the nightly builds). just need to finish the documentation.
).