Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

12045 Posts in 1593 Topics- by 593 Members - Latest Member: zhang

25. May 2013, 12:58:22 am
Xith3D CommunityGeneral CategoryNews (Moderators: Marvin Fröhlich, 'n ddrylliog)JAGaToo's new InputSystem is ready!
Pages: 1 [2] 3
Print
Author Topic: JAGaToo's new InputSystem is ready!  (Read 9496 times)
Marvin Fröhlich
Xith Lord
Administrator
Guru
*****
Offline Offline

Posts: 4403


May the 4th, be with you...


View Profile
« Reply #15 on: 03. May 2008, 10:53:23 pm »

In fact, the warning appears only when you are in LWJGL and lines #383-388 are enabled. (the testcase by default Wink )

The reason, why it doesn't warn in AWT mode is, that the pure-AWT InputDeviceFactory was used. Please see lines #512/513 (after an SVN update). Now I have switched to the AWTJInputInputDeviceFactory to enabled Controller support for AWT. Actually, the Controller support doesn't come from AWT, but from JInput (AWT doesn't have Controller support). Since JInput doesn't currently provide a possibility to read out just the Controllers, but always provides a list with ALL devices, from which you have to select just the Controllers, JInput-Keyboard instances are always created. So there's nothing I can do to avoid this message, if you want Controller support.

I will ask at the JInput forum, if they can do anything for it.

For the null pointer i still have exceptions:
With LWJGL :
...

With AWT:
...

Fixed.

Marvin
Logged
qbproger
developers
Becoming dependent
***
Offline Offline

Posts: 217


View Profile
« Reply #16 on: 02. June 2008, 05:08:31 pm »

I know this is late, but I just updated to the new input system.

If I understand correctly to register SWT/AWT/Swing now, you have to implement InputSourceWindow on your own, and then register that with the input system.

I guess I was expecting to find SWTSourceWindow/AWTSourceWindow...
Logged

Marvin Fröhlich
Xith Lord
Administrator
Guru
*****
Offline Offline

Posts: 4403


May the 4th, be with you...


View Profile
« Reply #17 on: 02. June 2008, 06:06:57 pm »

I know this is late, but I just updated to the new input system.

If I understand correctly to register SWT/AWT/Swing now, you have to implement InputSourceWindow on your own, and then register that with the input system.

I guess I was expecting to find SWTSourceWindow/AWTSourceWindow...

The documentation, you're referring to, is usage- and integration-independent. Therefore I couldn't write anything about existing integrations like the Xith3D's one there.

Xith3D already has implementations for this interface. You can get them through canvas.getPeer(). You don't have to write your own implementation of InputSourceWindow when using Xith3D. Just use it like it is used in all of the testcases.

Watch out for these lines:
Code:
InputSystem.getInstance().registerNewKeyboardAndMouse( canvas.getPeer() );

The InputSystem testcase in the JAGaToo repository uses simple implementations of this interface. Just have a look at the testcase.

Marvin
Logged
qbproger
developers
Becoming dependent
***
Offline Offline

Posts: 217


View Profile
« Reply #18 on: 02. June 2008, 09:06:50 pm »

The SWT stuff in the InputManager doesn't work.

I was able to get the keyboard to work, but wasn't able to get the mouse to work.  I don't have too much time to continue working on this, so I'm going to revert, but I'll give you the fixes I've made thus far.

SWTKeyboard:
line 281 should be this:
Code:
final org.eclipse.swt.opengl.GLCanvas control = (org.eclipse.swt.opengl.GLCanvas)sourceWindow.getDrawable();
I think there is a line similar to this in SWTMouse.  It's currently causing a null pointer exception because GLCanvas can't be cast to a Control.

The org.eclipse.swt.events.KeyEvent _e.time should not be used at all.  Instead of _e.time System.nanoTime() should be used.  _e.time values are all over the place, almost random.  I looked into using it for a while and couldn't figure out how to get it working with that in there.  This change applies to both SWTMouse and SWTKeyboard.

line 165 (The function should look like this):
Code:
    public static org.jagatoo.input.devices.components.Key convertKey( org.eclipse.swt.events.KeyEvent ev )
    {
    if(KEYCODE_CONVERSION.get(ev.keyCode) != null)
    {
            return( KEYCODE_CONVERSION.get( ev.keyCode ) );
    }
    else
    {
    return CHAR_CONVERSION.get( Character.toLowerCase( ev.character ));
    }
    }

It's currently checking for a NullPointerException that will never be thrown.  If something isn't in a map it will return null rather than throwing a NullPointerException.

With all this done, the Keyboard input will begin to work, but the mouse does not.  I may take another shot at updating in the future.

If someone else has time to look at the mouse issue it'd be appreciated.
Logged

Marvin Fröhlich
Xith Lord
Administrator
Guru
*****
Offline Offline

Posts: 4403


May the 4th, be with you...


View Profile
« Reply #19 on: 02. June 2008, 09:52:05 pm »

Thanks for the effort.

SWTKeyboard:
line 281 should be this:
Code:
final org.eclipse.swt.opengl.GLCanvas control = (org.eclipse.swt.opengl.GLCanvas)sourceWindow.getDrawable();
I think there is a line similar to this in SWTMouse.  It's currently causing a null pointer exception because GLCanvas can't be cast to a Control.

That's strange, since
org.eclipse.swt.widgets.Control
is a super-super-super-super-class of
org.eclipse.swt.opengl.GLCanvas
Therefore the cast should be absolutely no problem. And I would prefer to use the most general type here. Please doublecheck, if this case really is not possible and in case, why not, since it should be.
It is line #288 btw.

The org.eclipse.swt.events.KeyEvent _e.time should not be used at all.  Instead of _e.time System.nanoTime() should be used.  _e.time values are all over the place, almost random.  I looked into using it for a while and couldn't figure out how to get it working with that in there.  This change applies to both SWTMouse and SWTKeyboard.

I think, I can fix that.

line 165 (The function should look like this):
Code:
    public static org.jagatoo.input.devices.components.Key convertKey( org.eclipse.swt.events.KeyEvent ev )
    {
    if(KEYCODE_CONVERSION.get(ev.keyCode) != null)
    {
            return( KEYCODE_CONVERSION.get( ev.keyCode ) );
    }
    else
    {
    return CHAR_CONVERSION.get( Character.toLowerCase( ev.character ));
    }
    }

It's currently checking for a NullPointerException that will never be thrown.  If something isn't in a map it will return null rather than throwing a NullPointerException.

Fixed.

Marvin
Logged
qbproger
developers
Becoming dependent
***
Offline Offline

Posts: 217


View Profile
« Reply #20 on: 02. June 2008, 10:59:08 pm »

Quote
That's strange, since
org.eclipse.swt.widgets.Control
is a super-super-super-super-class of
org.eclipse.swt.opengl.GLCanvas
Therefore the cast should be absolutely no problem. And I would prefer to use the most general type here. Please doublecheck, if this case really is not possible and in case, why not, since it should be.
It is line #288 btw.

That may be true.  I'm not sure when I'll take another stab at getting the latest in SVN working again.  When/If I do I'll check that again.
Logged

qbproger
developers
Becoming dependent
***
Offline Offline

Posts: 217


View Profile
« Reply #21 on: 08. July 2008, 09:52:23 pm »

Ok, I'm taking another crack at this.

CanvasPeerImplSWT.getDrawable() needs to make a call to ensureSWT() before returning the glCanvas.  I was getting a null pointer exception in SWTKeyboard.java at line 291 because it was null.

SWTKeyboard:
line 281 should be this:
Code:
final org.eclipse.swt.opengl.GLCanvas control = (org.eclipse.swt.opengl.GLCanvas)sourceWindow.getDrawable();
I think there is a line similar to this in SWTMouse.  It's currently causing a null pointer exception because GLCanvas can't be cast to a Control.

That's strange, since
org.eclipse.swt.widgets.Control
is a super-super-super-super-class of
org.eclipse.swt.opengl.GLCanvas
Therefore the cast should be absolutely no problem. And I would prefer to use the most general type here. Please doublecheck, if this case really is not possible and in case, why not, since it should be.
It is line #288 btw.

I double checked this, and you are right, it doesn't need to be cast to a GLCanvas.  Casting to a Control is fine.

Also, in InputSystemException it's helpful if you add this.setStackTrace( cause.getStackTrace() ) so that you can see the line that caused the exception rather than the line where the new exception was created.  I added this in 3 places in there.

qb
Logged

Marvin Fröhlich
Xith Lord
Administrator
Guru
*****
Offline Offline

Posts: 4403


May the 4th, be with you...


View Profile
« Reply #22 on: 08. July 2008, 10:46:49 pm »

Could you please paste the exception without the setStacktrace() and the one with it? I wonder, why there isn't the cause of the InputSystemException, that should show you the actual line.

Marvin
Logged
qbproger
developers
Becoming dependent
***
Offline Offline

Posts: 217


View Profile
« Reply #23 on: 09. July 2008, 12:40:42 pm »

Could you please paste the exception without the setStacktrace() and the one with it? I wonder, why there isn't the cause of the InputSystemException, that should show you the actual line.

Marvin

without my change:
Code:
org.jagatoo.input.InputSystemException
at org.jagatoo.input.impl.swt.SWTKeyboard.<init>(SWTKeyboard.java:352)
at org.jagatoo.input.impl.swt.SWTInputDeviceFactory.initKeyboards(SWTInputDeviceFactory.java:83)
at org.jagatoo.input.impl.swt.SWTInputDeviceFactory.initKeyboards(SWTInputDeviceFactory.java:1)
at org.jagatoo.input.devices.InputDeviceFactory.getKeyboards(InputDeviceFactory.java:221)
at org.jagatoo.input.InputSystem.registerNewKeyboard(InputSystem.java:417)
at org.jagatoo.input.InputSystem.registerNewKeyboardAndMouse(InputSystem.java:795)
at org.jagatoo.input.InputSystem.registerNewKeyboardAndMouse(InputSystem.java:808)
at com.ara.engen.ui.views.viewer3d.A3dViewerView.createPartControl(A3dViewerView.java:192)
at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:305)
at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:180)
at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:552)
at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:283)
at org.eclipse.ui.internal.ViewPane.setVisible(ViewPane.java:512)

With my change:
Code:
org.jagatoo.input.InputSystemException
at org.jagatoo.input.impl.swt.SWTKeyboard.<init>(SWTKeyboard.java:291)
at org.jagatoo.input.impl.swt.SWTInputDeviceFactory.initKeyboards(SWTInputDeviceFactory.java:83)
at org.jagatoo.input.impl.swt.SWTInputDeviceFactory.initKeyboards(SWTInputDeviceFactory.java:1)
at org.jagatoo.input.devices.InputDeviceFactory.getKeyboards(InputDeviceFactory.java:221)
at org.jagatoo.input.InputSystem.registerNewKeyboard(InputSystem.java:417)
at org.jagatoo.input.InputSystem.registerNewKeyboardAndMouse(InputSystem.java:795)
at org.jagatoo.input.InputSystem.registerNewKeyboardAndMouse(InputSystem.java:808)
at com.ara.engen.ui.views.viewer3d.A3dViewerView.createPartControl(A3dViewerView.java:192)
at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:305)
at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:180)
at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:552)
at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:283)
at org.eclipse.ui.internal.ViewPane.setVisible(ViewPane.java:512)

With my change the first line of the exception gives the line number where the exception occurred, rather than the line where the new exception is thrown.
Logged

Marvin Fröhlich
Xith Lord
Administrator
Guru
*****
Offline Offline

Posts: 4403


May the 4th, be with you...


View Profile
« Reply #24 on: 09. July 2008, 01:09:19 pm »

Well, as you can see in SWTKeyboard line 352, the InputSystemException is thrown with a cause. I assume, your pasted stacktrace is incomplete. Could you please paste the complete stacktrace with all "caused by" blocks? the stacktrace, you're interested in should be the second block (first caused by).

Marvin
Logged
qbproger
developers
Becoming dependent
***
Offline Offline

Posts: 217


View Profile
« Reply #25 on: 09. July 2008, 02:19:36 pm »

Well, as you can see in SWTKeyboard line 352, the InputSystemException is thrown with a cause. I assume, your pasted stacktrace is incomplete. Could you please paste the complete stacktrace with all "caused by" blocks? the stacktrace, you're interested in should be the second block (first caused by).

Marvin

There was more farther down, you're probably right.
Logged

qbproger
developers
Becoming dependent
***
Offline Offline

Posts: 217


View Profile
« Reply #26 on: 15. July 2008, 07:45:41 pm »

A few more bugs in the SWTMouse:

private void updateCenters() should look like this:
I was getting an exception for trying to access SWT widgets outside of the SWT thread, this is a way to do that.  I used asyncExec instead of syncExec because syncExec would just hang.  Also, the size wasn't getting returned correctly.
Code:
    private void updateCenters()
    {
        // calculate center-of-component (in absolute sizes)
        control.getDisplay().asyncExec( new Runnable()
        {
            public void run()
            {
                los.x = control.getLocation().x;
                los.y = control.getLocation().y;
               
                Composite parent = control.getParent();
                while ( parent != null )
                {
                    los.x += parent.getLocation().x;
                    los.y += parent.getLocation().y;
                   
                    parent = parent.getParent();
                }
               
                centerControl.x = ( control.getSize().x / 2 ) + 1;
                centerControl.y = ( control.getSize().y / 2 ) + 1;
               
                parent = control.getParent();
                while ( ( centerControl.x == 1 && centerControl.y == 1 ) && ( parent != null ) )
                {
                    centerControl.x = ( parent.getSize().x / 2 ) + 1;
                    centerControl.y = ( parent.getSize().y / 2 ) + 1;
                   
                    parent = parent.getParent();
                }
               
                calibrationStep = 0;
            }
        } );
    }

private void recenter() Should be changed to this: (this is the same type of issue as above)
Code:
private void recenter() throws InputSystemException
    {
        if ( control.getDisplay().getThread().equals( Thread.currentThread() ) )
        {
            control.getDisplay().setCursorLocation( los.x + calibX + centerControl.x, los.y + calibY + centerControl.y );
        }
        else
        {
            control.getDisplay().asyncExec( new Runnable()
            {
                public void run()
                {
                    control.getDisplay().setCursorLocation( los.x + calibX + centerControl.x, los.y + calibY + centerControl.y );
                }
            } );
        }
    }

There are only 2 remaining issues.

The mouse wheel doesn't work correctly (as it did in the previous revision).
The mouse cursor doesn't disappear when over the 3D canvas.

If you have any incite into either of these issues, it'd be helpful Smiley

For the mouse wheel issue I did try this, which didn't work (it was currently using _e.time() which definitely wouldn't work.  I was hoping just switching to the System.nanoTime() would fix it):
Code:
long when = System.nanoTime() - lastGameTimeDelta;
                   
                    //MouseWheelEvent e = MouseEventPool.allocWheel( SWTMouse.this, getWheel(), -_e.count, false, when, 0L );
                    MouseWheelEvent e = prepareMouseWheelMovedEvent( -_e.count, false, when );

I'm not sure at all about making the cursor hidden.
Logged

qbproger
developers
Becoming dependent
***
Offline Offline

Posts: 217


View Profile
« Reply #27 on: 15. July 2008, 08:20:01 pm »

I should have been more clear.  The mouse wheel not working correctly means it'll zoom in and out, but not every time I move the mouse wheel.  It will happen some of the time though.

The _e.count with 1 mouse wheel click down equals -3.  For 1 mouse wheel click up it's 3.  I don't know what the numbers are for AWT, so I can't compare.  I'll keep looking into it, let me know if something comes to mind.
Logged

Marvin Fröhlich
Xith Lord
Administrator
Guru
*****
Offline Offline

Posts: 4403


May the 4th, be with you...


View Profile
« Reply #28 on: 15. July 2008, 08:42:30 pm »

I have no idea for the mouse wheel thing. It may also be related to SWT threading. But this is just a raw guess.

As for hiding the cursor: This is due to an unimplemented method. Please add an implementation of orgg.xith3d.render.jsr231.CanvasPeerImplSWT::refreshCursor(). You may want to have a look at the AWT or LWJGL implementations for examples.

You may want to send me your sourceforge nick, so that I can add you as a developer to the three projects. Then you could just commit these changes yourself.

Marvin
Logged
qbproger
developers
Becoming dependent
***
Offline Offline

Posts: 217


View Profile
« Reply #29 on: 16. July 2008, 02:13:50 pm »

I have no idea for the mouse wheel thing. It may also be related to SWT threading. But this is just a raw guess.

This bug also shows itself in JOGL_AWT.

To recreate in the test launcher (I'm using the head of Jagatoo/Xith3D):
JOGL_AWT
800x600x16x59
Fullscreen off
V-Sync on
FSAA: OFF
Mouse-Y inverted off

FirstPersonInputHandlerTest

If you scroll a lot it'll zoom a little bit.  I just discovered this and plan on looking into what's different in LWJGL.
Logged

Pages: 1 [2] 3
Print
Jump to:  

Theme orange-lt created by panic