Deployment Problem

[Neoteric]

I'm having problems including the JPCT classes into the JAR file, how was it done in the examples? It might just be a problem with my copy of jBuilder.

[EgonOlsen]

I'm always using the JAR-utility that comes with the JDK. I once tried to include a project's classes and all associated libs into a jar using JBuilder and i failed (not saying that it isn't possible though), so i reverted to the JDK's JAR-utility.

[Neoteric]

Cool, I'll try it.

And onother question, wow easy would it be to use a model with bones?

[EgonOlsen]

And onother question, wow easy would it be to use a model with bones?

For doing animations?

[Neoteric]

For doing animations?

yep.

I'm getting there deploying, but when I load the JAR explorer is saying there's a null pointer exception for some reason.

[EgonOlsen]

yep.

jPCT doesn't support this ATM. However, it supports keyframed animations either directly loaded from a MD2-file (quake2 model format) or done "by hand". I suggest to convert the animations into keyframes and let jPCT interpolate between them. Support for other kinds of animation is on my list, but with a very low priority, so don't count on it.

I'm getting there deploying, but when I load the JAR explorer is saying there's a null pointer exception for some reason.

That's a bit too vague...in your code or in mine?

[Neoteric]

jPCT doesn't support this ATM. However, it supports keyframed animations either directly loaded from a MD2-file (quake2 model format) or done "by hand". I suggest to convert the animations into keyframes and let jPCT interpolate between them. Support for other kinds of animation is on my list, but with a very low priority, so don't count on it.

Ok, cool.

That's a bit too vague...in your code or in mine?

Your classes but I think the problem is my end, everything is included in the archive fine, it can find the classes, but on frame buffer instantiation it throws the exception. I think it's a packgage problem.

[EgonOlsen]

Your classes but I think the problem is my end, everything is included in the archive fine, it can find the classes, but on frame buffer instantiation it throws the exception. I think it's a packgage problem.

Are you sure that you've included BufferedImageBuffer and MemoryImageBuffer into the JAR? jPCT doesn't do very much in the instantiation of a FrameBuffer that may cause this exception but it dynamically loads one of these classes depending on the VM (Memory... for 1.1 and Buffered...for 1.2+). Maybe this fails because the classes are not there? Does it output some blah before it crashes? Like "java version is:"??

[Neoteric]

Your classes but I think the problem is my end, everything is included in the archive fine, it can find the classes, but on frame buffer instantiation it throws the exception. I think it's a packgage problem.

Are you sure that you've included BufferedImageBuffer and MemoryImageBuffer into the JAR? jPCT doesn't do very much in the instantiation of a FrameBuffer that may cause this exception but it dynamically loads one of these classes depending on the VM (Memory... for 1.1 and Buffered...for 1.2+). Maybe this fails because the classes are not there? Does it output some blah before it crashes? Like "java version is:"??

I fixed the problem by taking the main class out of it's package, now the JAR runs from my HD but I still get the same problem when running off of the web, I think it can't find the textures. It just says Java.lang.NullPointerException.

[EgonOlsen]

Are the textures/models part of the JAR? If so, you may have to use the "InputStream"-methods/contructors  to access them. Or, if they aren't part of the JAR, the methods/contructors with "URL" are what you need. Either that or try adjusting the applet-params like setting codebase="." or something.

Edit: Another thing that may fool you: Windows in not case-sensitive, so loading "HuRz.Jpg" will work even if the file is named "hurz.jpg" on the HD. On a webserver, this won't work though. Just a thought...

Edit2: OT: A new version (0.87) is out which major improvement is a much more accurate lookAt()-method. If you're using (or plan to use) this method, you should get the update.

[Anonymous]

Are the textures/models part of the JAR? If so, you may have to use the "InputStream"-methods/contructors  to access them. Or, if they aren't part of the JAR, the methods/contructors with "URL" are what you need. Either that or try adjusting the applet-params like setting codebase="." or something.

Good stuff, changed it to streams and it worked fine.

Edit2: OT: A new version (0.87) is out which major improvement is a much more accurate lookAt()-method. If you're using (or plan to use) this method, you should get the update.

I was just about to ask about that, MUCH better.

Does the openGL version offer any speed up yet? Last I remember it didn't.

[EgonOlsen]

Does the openGL version offer any speed up yet? Last I remember it didn't.

:shock: ...??...but...but..it should... :wink: The hardware support via LWJGL is way faster than the software modes. If it isn't, OpenGL may run in software emulation (done by the OpenGL implementation, not by jPCT) for some reason but i doubt that this will even work. There are three rendering modes in jPCT: software legacy (default), software OpenGL-look-a-like (a bit slower than legacy but using OpenGL's lighting model) and finally the hardware OpenGL renderer itself. Try the terrain example in OpenGL. It should be much faster (around 10 times on my machine) than the software rendered version.
Two problems with LWJGL though:

1.) It doesn't work in an applet (a security problem which has to fixed by the LWJGL-team...nothing i can about it)
2.) No support for AWT/Swing stuff in the OpenGL window (a design decision of LWJGL)

Does this answer your question somehow?

[Neoteric]

Does the openGL version offer any speed up yet? Last I remember it didn't.

:shock: ...??...but...but..it should... :wink: The hardware support via LWJGL is way faster than the software modes. If it isn't, OpenGL may run in software emulation (done by the OpenGL implementation, not by jPCT) for some reason but i doubt that this will even work. There are three rendering modes in jPCT: software legacy (default), software OpenGL-look-a-like (a bit slower than legacy but using OpenGL's lighting model) and finally the hardware OpenGL renderer itself. Try the terrain example in OpenGL. It should be much faster (around 10 times on my machine) than the software rendered version.

I can't get the landscape demo to work since the GL version was released, I'll have a mess about with the .bat file. I remember reading somewhere that there wasn't much performace increase with the first version, might just have been my imagination.

Are the LWJGL-team working on problem 1? That would be very useful, the artist I'm working with at the moment is using 600+ polygons for the characters which can be a big strain on the software mode with older processors. I'll post details here when the alpha is finally up.

EDIT: I changed the BAT, that's MUCH faster!

[EgonOlsen]

Are the LWJGL-team working on problem 1?

They mentioned it some time ago, but i think the priority is not very high. They seem to favour Java WebStart instead.