next »

['n ddrylliog]

bluesky@bluesky-desktop:~/Desktop/Stratagem-Alpha1$ java -classpath stratagem.jar:classic.jar:xith-tk.jar:xith3d.jar:hial.jar:vecmath-kh.jar:lwjgl.jar -Djava.library.path=./ org.stratagem.apps.Stratagem
Exception in thread "main" java.lang.NoClassDefFoundError: javax/media/opengl/GLCapabilitiesChooser
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
        at org.xith3d.render.canvas.utils.CanvasUtilsJSR231.setGLCapsDebug(CanvasUtilsJSR231.java:56)
        at org.xith3d.render.canvas.Canvas3DWrapper.setGLCapsDebug(Canvas3DWrapper.java:647)
        at org.xith3d.render.canvas.Canvas3DWrapper.<init>(Canvas3DWrapper.java:664)
        at org.xith3d.render.canvas.Canvas3DWrapper.<init>(Canvas3DWrapper.java:893)
        at org.xith3d.render.canvas.Canvas3DWrapper.<init>(Canvas3DWrapper.java:928)
        at org.stratagem.apps.Stratagem.init3D(Stratagem.java:113)
        at org.stratagem.apps.Stratagem.start(Stratagem.java:63)
        at org.stratagem.apps.Stratagem.main(Stratagem.java:42)

setGLCapsDebug should only be called if((layer==OpenGLLayer.JOGL_AWT)||(layer==OpenGLLayer.JOGL_SWT))

['n ddrylliog]

Fixed.

Anyway, is this crappy OldStyleGLCapabilitiesChooser really used anymore ? Why are there an Old and a regular GL Capabilities Chooser ?

[Marvin Fröhlich]

Fixed.

Anyway, is this crappy OldStyleGLCapabilitiesChooser really used anymore ? Why are there an Old and a regular GL Capabilities Chooser ?

How did you fix that? I eliminated the need for the classes in org.xith3d.render.canvas.utils.* about three days ago. They were exactly to avoid such problems, but the way I went now is much better. I used late binding through class.forName() to get instances of CanvasPeer. Were you using an older Xith version and the problem was fixed by these changes or did you do anything to solve it? I haven't seen any commit? I just want to be sure, that I have the latest version .

Marvin

[Marvin Fröhlich]

Fixed.

Anyway, is this crappy OldStyleGLCapabilitiesChooser really used anymore ? Why are there an Old and a regular GL Capabilities Chooser ?

Oh, btw. If anybody uses GLCapabilitesChoose or GLCapabilites, please tell me. Everything should be available abstractly though the constructors (for all opengl layers). If it is not, we need to extend the constructors.

[Marvin Fröhlich]

@Amos: You surrounded the setGLCapsDebug() call in Canvas3DWrapper with an if-selection about the current OpenGLLayer. Why did you do that? The only thing, this method does, is setting a Boolean. Did it solve any dependancy issue for you? If it did, please try it without it for the current xith version. It should work without it. If it does, I will remove the if-selection. FYI: I modified the behaviour if this method recently.

Marvin

['n ddrylliog]

Yep, adding the "if" fixed my problem, because the call caused the JVM to load a JOGL class, which wasn't in the classpath.

Anyway, why remove it ? GL Debug dump for JOGL shouldn't be switched on when you're not using JOGL, isn't it ?

[Marvin Fröhlich]

Yep, adding the "if" fixed my problem, because the call caused the JVM to load a JOGL class, which wasn't in the classpath.

Anyway, why remove it ? GL Debug dump for JOGL shouldn't be switched on when you're not using JOGL, isn't it ?

Have a look at, what this method really does. It has nothing to do with JOGL at this time. So removing it just can't solve any dependancy problems. Strange. I will check it...

Marvin

['n ddrylliog]

Well, go tell that to the JVM  Maybe it was before it changed.