next »

[SephirXV]

I'm having a bit of an issue and was wondering if anyone else has seen anything like this.

I got my InputHandler ported to run on SVN, and am using the provided/included StatesManager/BindingsManager. My InputHandler has not concept of acceleration (yet), either it should be moving at full speed as indicated by the input, or it should be moving at all. Each frame, it polls the states manager as to whether the key for a specific motion is pressed, if so it applies motion scaled to the time for that frame.

It works as advertised in short to medium bursts, but I've noticed that if I hold a key for 2-3 seconds then release it, my View keeps moving forward, until I quickly press and release the same key.

This particular InputHandler optimizes itself by detecting inputs for opposing directions that would cancel each other out, and simply ignoring both of them. When stuck moving as above, pressing the opposing motion button will halt the motion until released, in which case it will resume it's stuck motion. So I know it's not my math, I think the states manager is actually reporting the wrong state.

Although I've no real idea how the JAGaToo states managers work, it seems to me that if they were listeners, and used KeyPressed/KeyReleased events to indicate when to change a state and in which direction (T>F, F>T), then it would be as if it got the KeyPressed event, but missed the matching KeyReleased, and then later when I quickly tap the same key, the KeyPressed has no effect since the state is already true, but it catches the KeyReleased and finally changes back to false. Furthermore, if I recall, some implementations send repeated KeyPressed's (like typomatic on your keyboard), which could saturate a queue, while others send only on state change, so perhaps this is implementation-specific?

I'm hoping someone has run into something like this before, posting the relevant parts of my update method would take allot of screen space.

[Marvin Fröhlich]

You're using JOGL_AWT, which relies on AWT input. AWT input is quite unusable for actual gaming. Just switch to LWJGL and your problems will be solved (and you will get faster rendering ).

The problem is indeed rooted in the key-repeat events. AWT fires repeated key-pressed and key-released events when it actually should only send repeated key-typed events. And since these events come from a separate AWT-input thread, it's unfortunately improssible to properly track these events. Mathias and I have spent s lot of time trying to fix this problem, but couldn't find a way. If you see a way to fix it, don't hesitate to post a fix.

LWJGL doesn't have this problem, since it uses polled input and doesn't send useless events. Hence it is much more (and absolutely) reliable. LWJGL is anyway better is almost any point.

...posting the relevant parts of my update method would take allot of screen space.

If you posted it in a code-block, it would not take too much screen space from the sctual thread .

Marvin

[SephirXV]

If you posted it in a code-block, it would not take too much screen space from the sctual thread .

Can you tell I'm a newb to programming forums?

When trying LWJGL, I get the following:

Code:

Exception in thread "main" java.lang.LinkageError: Version mismatch: jar version is '19', native libary version is '11'
at org.lwjgl.Sys.<clinit>(Sys.java:103)
at org.lwjgl.opengl.Display.<clinit>(Display.java:128)
at org.xith3d.render.lwjgl.DisplayModeSelectorNativeImpl.getAvailableModes(DisplayModeSelectorNativeImpl.java:68)
at org.xith3d.render.config.DisplayModeSelector.getBestMode(DisplayModeSelector.java:134)
at org.xith3d.render.Canvas3DFactory.createDisplayMode(Canvas3DFactory.java:57)
at org.xith3d.render.Canvas3DFactory.createDisplayMode(Canvas3DFactory.java:70)
at org.xith3d.render.Canvas3DFactory.create(Canvas3DFactory.java:456)
at org.xith3d.render.Canvas3DFactory.createWindowed(Canvas3DFactory.java:750)
at org.xith3d.render.Canvas3DFactory.createWindowed(Canvas3DFactory.java:808)
at org.xith3d.render.Canvas3DFactory.createWindowed(Canvas3DFactory.java:835)
at sephirxv.jig.Test.<init>(Test.java:68)
at sephirxv.jig.Test.main(Test.java:60)

As far as I can tell it's using the SVN jar, My project has the xith3d svn in it's build path, it used to include all the jars required, but I removed them from the build path, and then renamed the directory they were in to be sure. The link in the xith3d build path for lwjgl's natives seems to be pointed to the right directory.

LWJGL_AWT tells me the CanvasPeerImplAWT must be used with an owner (integrated into an AWT/Swing environment), which I can only assume means I need to provide a (J)Frame or something similar and then attach the canvas3d to it. But does LWJGL suffer the same input problem, or does it use the polling?

[Marvin Fröhlich]

Can you tell I'm a newb to programming forums?

When trying LWJGL, I get the following:

Code:

Exception in thread "main" java.lang.LinkageError: Version mismatch: jar version is '19', native libary version is '11'
at org.lwjgl.Sys.<clinit>(Sys.java:103)
at org.lwjgl.opengl.Display.<clinit>(Display.java:128)
at org.xith3d.render.lwjgl.DisplayModeSelectorNativeImpl.getAvailableModes(DisplayModeSelectorNativeImpl.java:68)
at org.xith3d.render.config.DisplayModeSelector.getBestMode(DisplayModeSelector.java:134)
at org.xith3d.render.Canvas3DFactory.createDisplayMode(Canvas3DFactory.java:57)
at org.xith3d.render.Canvas3DFactory.createDisplayMode(Canvas3DFactory.java:70)
at org.xith3d.render.Canvas3DFactory.create(Canvas3DFactory.java:456)
at org.xith3d.render.Canvas3DFactory.createWindowed(Canvas3DFactory.java:750)
at org.xith3d.render.Canvas3DFactory.createWindowed(Canvas3DFactory.java:808)
at org.xith3d.render.Canvas3DFactory.createWindowed(Canvas3DFactory.java:835)
at sephirxv.jig.Test.<init>(Test.java:68)
at sephirxv.jig.Test.main(Test.java:60)

As far as I can tell it's using the SVN jar, My project has the xith3d svn in it's build path, it used to include all the jars required, but I removed them from the build path, and then renamed the directory they were in to be sure. The link in the xith3d build path for lwjgl's natives seems to be pointed to the right directory.

Unfortunately I've never seen an exception like that. Do you possibly have some LWJGL natives in your jre/bin folder or somethere else inside of the java installation folder?

Do the xith-tk testcases work with LWJGL? Please try to run the Xith3DTestLauncher and select LWJGL (not LWJGL_AWT). If it does work, please compare your own project's build path with the xith-tk's one.

LWJGL_AWT tells me the CanvasPeerImplAWT must be used with an owner (integrated into an AWT/Swing environment), which I can only assume means I need to provide a (J)Frame or something similar and then attach the canvas3d to it. But does LWJGL suffer the same input problem, or does it use the polling?

LWJGL_AWT uses AWT input. So it won't help you here. And your assumption about the (J)Frame is correct. Though the simples way to use it would be to use a CanvasPanel with LWJGL_AWT. But don't use it, if you don't need a surrounding AWT/Swing environment. For a stand alone game LWJGL (without _AWT) is the preferred layer.

Marvin

[SephirXV]

As far as the build path window in Eclipse is concerned, my project and xith-tk are identical.

Running LWJGL windowed @ 800x600x32x75, VSync on, FSAA off, I got

Code:

Exception in thread "AWT-EventQueue-0" java.lang.LinkageError: Version mismatch: jar version is '19', native libary version is '11'
at org.lwjgl.Sys.<clinit>(Sys.java:103)
at org.lwjgl.opengl.Display.<clinit>(Display.java:128)
at org.xith3d.render.lwjgl.DisplayModeSelectorNativeImpl.getAvailableModes(DisplayModeSelectorNativeImpl.java:68)
at org.xith3d.render.config.DisplayModeSelector.getBestMode(DisplayModeSelector.java:134)
at org.xith3d.utility.launching.DisplayOptions.getCurrentDisplayMode(DisplayOptions.java:531)
at org.xith3d.utility.launching.DisplayOptions.refillDisplayModeSelector(DisplayOptions.java:409)
at org.xith3d.utility.launching.DisplayOptions.actionPerformed(DisplayOptions.java:318)
at org.xith3d.test.Xith3DTestLauncher.actionPerformed(Xith3DTestLauncher.java:232)
at javax.swing.JComboBox.fireActionEvent(JComboBox.java:1242)
at javax.swing.JComboBox.setSelectedItem(JComboBox.java:569)
at javax.swing.JComboBox.setSelectedIndex(JComboBox.java:605)
at javax.swing.plaf.basic.BasicComboPopup$Handler.mouseReleased(BasicComboPopup.java:814)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:273)
at java.awt.Component.processMouseEvent(Component.java:6038)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3260)
at javax.swing.plaf.basic.BasicComboPopup$1.processMouseEvent(BasicComboPopup.java:480)
at java.awt.Component.processEvent(Component.java:5803)
at java.awt.Container.processEvent(Container.java:2058)
at java.awt.Component.dispatchEventImpl(Component.java:4410)
at java.awt.Container.dispatchEventImpl(Container.java:2116)
at java.awt.Component.dispatchEvent(Component.java:4240)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
at java.awt.Container.dispatchEventImpl(Container.java:2102)
at java.awt.Window.dispatchEventImpl(Window.java:2429)
at java.awt.Component.dispatchEvent(Component.java:4240)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
Exception in thread "Xith3DTestLauncher Thread" java.lang.NoClassDefFoundError: Could not initialize class org.lwjgl.opengl.Display
at org.xith3d.render.lwjgl.DisplayModeSelectorNativeImpl.getAvailableModes(DisplayModeSelectorNativeImpl.java:68)
at org.xith3d.render.config.DisplayModeSelector.getBestMode(DisplayModeSelector.java:134)
at org.xith3d.utility.launching.DisplayOptions.getCurrentDisplayMode(DisplayOptions.java:531)
at org.xith3d.test.Xith3DTestLauncher$1.run(Xith3DTestLauncher.java:203)

I'll run a search for lwjgl.jar & it's natives and see if there are any other hanging around in any of my JVM folders. Problem is won't be back at work till Monday, so I'll let you know then.

[SephirXV]

After trying to remove the jars/dlls I had spread across my VMs from running preSVN and then trying to fix all the ensuing problems that caused, I installed a new JDK and migrated Eclipse to it in hopes that I'd fix the problems I was having.

It turns out that I'd made a big (wrong) assumption all along: Not all the test cases work. ShooterDemo says that there's no keyboard for JAGaToo to register, and the RotatableGroupTest actually crashes the GL on my (admittedly POS) Intel Graphics, which took me awhile to track down because it crashed during the native code.

Are there allot of well-known, ongoing issues with some of the test cases, or should I take it to mean I still have bugs to work out before Xith is really running well? Should I be reporting these tests that fail?

All in all it was worth it though, because I got my project working (again), now using LWJGL, and it doesn't suffer the sticking problem I was encountering.

[Marvin Fröhlich]

Attachments to posts can be applied in the "create new post" screen, when expanding the "Additional Options..." link.

RUN_IN_SAME_THREAD is the default value for the begin() method. i.e. when invoked without a parameter, RUN_IN_SEPARATE_THREAD is assumed.

I have fixed the exception in the shooter demo. But please don't consider this demo as finished. Actually it is far away from that state. (But it doesn't crash anymore now)

I have fixed bullet-test. It was a problem with a misplaced cursor.

RotatableGroupTest is running fine on my system.

There have been other issues about unimplemented OpenGL functions in the ATI- and Intel drivers in the past. The ones, that I have encountered so far are already worked around. But there may be others. There is a debug LWJGL jar in the third party folder, which you can use to replace the non-debug one. Maybe it helps you to track the bug. I would need the method name, that causes the crash. It would be best to post the complete crash log.

Marvin

[SephirXV]

Okay, I'll sync, and then run a battery of tests against all the test cases, and make a new thread with the issues.