Woo! A working implementation! (I had to use mod_rewrite 'cause my server doesn’t seem to like the other method, but it still works.) Would everyone please do me a favour and try this out? It’s the Webstart-ed particle demo.
It has everything in the new jmetest.* package, and it’s built with my custom buildfile. Now it’s just a matter of changing a couple of lines to migrate the code to the mojomonkeycoding servers!
[On a somewhat related note, I added a target to build.xml - “webdist” - which signs the JAR file. I’ll upload the changes to CVS, but it requires a keystore. Where in the dir structure should I put it?]
Particle test works great.
Not sure what you mean by the new buil.xml requiring a keystore.
In order to sign a JAR, you need to use a digital key. Using the tools that come with the Java SDK, keys are stored in a keystore. So, in order to sign a JAR for web distribution, you need to have the keystore containing the right key. The question is: where in the CVS tree should the keystore be placed?
Oh, I see. Is this something that should be kept out of public notice? I.e. is it supposed to stay secure? If not, I say just make a new directory for things such as the keystore, license files, etc. You can call it whatever you like.
I’ve opted for a compromise. I’ve uploaded the new build files and the keystore, but without the password required to access it. We can distribute the password as you wish. Perhaps an email to all developers? It’s up to you.
Ok, models now support URL. So, let me know if you can run the model tests in webstart.
Hmm. I’ve converted TestMd2 to the new URL style, and all is well and good when I run the test locally. However, when I attempt to run the test through webstart it dies on model loading. I’m not quite sure where. Before I do up an exhaustive debug build to find exactly where it’s dying, would you have any idea? I’ve committed my updated version to CVS, so you can start there. Perhaps the fault is mine. Thanks.
Looking at the test, it looks fine to me. Only thing I can think of is the model isn’t being built into the texture correctly or something.
I did read something on javagaming.org about read versus readfully and blocking problems. So, I switched to readfully. Maybe that is the problem. I’ve check in the new version. See if that works.
Bah - guest == Me
EricTheRed=Eric W=Eric Woroshow. Yeah, that’s me. Very astute. I seem to be making a name for myself, for better or for worse. 
(And I also assume you were thought I was erikd, who is not me.)
I got everything to work on my site, I just need to transfer things to mojomonkeycoding.com and it’s all set. The link you sent me helped a lot - thanks for that.
(Now all we need is for the lwjgl team to endorse us, and we’ll be all set to usurp Xith3D! :P)
The readfully thing nailed it. It works beautifully now. Everyone can check it out here until it gets moved to its proper place. Now all that’s left to do is make Arman add URL methods to the sound package, and we’ll be all set! 8)
I’m curious: what did you change exactly? Do you have a link for the blocking/readfully thing?
http://java.sun.com/j2se/1.4.1/docs/api/java/io/DataInputStream.html#read(byte[])
mentions how read() blocks (which is what I was using before), and how
http://java.sun.com/j2se/1.4.1/docs/api/java/io/DataInput.html#readFully(byte[])
doesn’t block.
So, I just switched the two, didn’t require any other changes.
Ran the webstart link, it worked great. Let me know if you have any problems with the milkshape or ASE, because they don’t use data input streams, but read buffers.
sigh I tried to get the Milkshape ASCII loader working with Webstart, but no luck. It’s exhibiting the exact same behaviour as the MD2 demo did prior to you switching to readFully. Grr. So, I’ll defer to you in the hope that you can fix it. Hopefully it’ll be a simple solution!
I was afraid of that. I’ll try to figure out what is causing the problem. Unfortunately, since they use buffered readers it’s not the same issue. 
Yes! A question I can answer definitively, since I maintain that part of jME. 
Well, the “selected display mode is not valid” message occurs when the display mode you’ve attempted to run on the system doesn’t exist. That means that the combination of resolution, bit depth, and refresh rate can’t run on your system. Try playing with the values until you get something that works.
It’s failing for 640x480 16 bpp 60 Hz? If so, there is definately a problem we need to figure out. The most common culprit for device failure is the frequency of the monitor. So make sure it’s at 60 for now. If the lowest level doesn’t work, let us know.
Odd. Well, if you have some spare time you could try this:
import org.lwjgl.Display;
import org.lwjgl.DisplayMode;
...
DisplayMode[] modes = Display.getAvailableDisplayModes();
for (int i = 0; i < modes.length; i++) {
System.out.println(modes[i]);
}
That'll output all the display modes your display supports. Choose one from the list and try it with jME. Let me know what happens. Apart from that, I'd be hard pressed to tell you what's going on.
for me, the jmedemo-effects.TestParticleSystem.jnlp just crashes out at the end - debug.txt doesn’t say anything, but JUST before it exits, it looks like the console is printing out a NPE…
some of the log
Ignored exception: java.lang.NullPointerException
Ignored exception: JNLPException[category: Download Error : Exception: null : LaunchDesc: null ]
Ignored exception: JNLPException[category: Download Error : Exception: null : LaunchDesc: null ]
Feb 17, 2004 8:48:25 AM com.jme.app.SimpleGame start
INFO: Application started.
Feb 17, 2004 8:48:26 AM com.jme.system.PropertiesIO
INFO: PropertiesIO created
Feb 17, 2004 8:48:26 AM com.jme.system.PropertiesIO load
INFO: Read properties
...
Feb 17, 2004 8:49:44 AM com.jme.scene.Node attachChild
INFO: Child (FPS Counter) attached to this node
Feb 17, 2004 8:49:45 AM com.jme.app.SimpleGame start
INFO: Application ending.
aha, found the NPE
java.lang.NullPointerException
at com.jme.scene.state.LWJGLTextureState.set(Unknown Source)
at com.jme.scene.Spatial.setStates(Unknown Source)
at com.jme.scene.Spatial.onDraw(Unknown Source)
at com.jme.scene.Node.draw(Unknown Source)
at com.jme.scene.Spatial.onDraw(Unknown Source)
at com.jme.renderer.LWJGLRenderer.draw(Unknown Source)
at jmetest.effects.TestParticleSystem.render(Unknown Source)
at com.jme.app.SimpleGame.start(Unknown Source)
at jmetest.effects.TestParticleSystem.main(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.continueLaunch(Unknown Source)
at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
java.lang.NoClassDefFoundError: org/lwjgl/Display
your classpath seems wrong, either you have a stale version, or LWJGL is not in the classpath!
And yes it's not working on 640x480x16 60 freq. I know this res works, and higher I play some NWN.
Yeah, but that depends on Fullscreen, Alpha, Depth, Stencil buffer settings - which I don't know what 'EricTheRed' is using.