JInput integration in NEWT?

Hi

JInput is an API allowing to manipulate controllers (pads, joysticks, etc...), mouses and keyboards. I would like to use it but under Windows, it relies on DirectInput which is almost no more maintained by Microsoft which prefers working on XInput.

You can find its source code here:
http://java.net/projects/jinput/sources/svn/show/trunk

Would someone need such an API in NEWT? I would like to support controllers in my game.

What are the viable alternatives to DirectInput/XInput on Windows? StreamInput?

In my humble opinion, StreamInput is the only possibility, the traditional Windows event loop might not be fast enough for this and... I prefer relying on open source APIs ;)

Would it be difficult to adapt JInput to be built with GlueGen?

Is the use of JInput as a starting point a good idea whereas it does not use StreamInput?

Best regards.

Edit.: The Windows Message Pump is explained a bit here:
http://programming4.us/Multimedia/3930.aspx

Edit2.: Raw inputs on Windows are explained here:
http://msdn.microsoft.com/en-us/library/ms645536%28v=vs.85%29.aspx

Edit3.: Actually, JInput can use raw input or DirectX, it is better than I thought

Edit4.: The raw input only allows to manipulate the keyboards and the mice :(

On Thursday, September 08, 2011 04:47:34 PM gouessej [via jogamp] wrote:
First of all, yes - extending input facilities are very essential.

In a general manner we added 'multitouch' a while ago (proposals)
  - http://jogamp.org/git/?p=jogl.git;a=commit;h=ae51b15c98af2ce462cb8ff1a237dd0c51e78e80
  - http://jogamp.org/git/?p=jogl.git;a=commit;h=bbbf51acf183b6fe696afd009d0ae49f6745bc40

See the current 'layout' of MouseEvent:
  http://jogamp.org/git/?p=jogl.git;a=blob;f=src/newt/classes/com/jogamp/newt/event/MouseEvent.java;h=62a8941d7753482932a03d7f4176e3b0f15ab004;hb=444eaa259116f7985711164512607ad46015fa4b

This shall demonstrate the generic nature of how we may add things IMHO.

So there are at least 2 ways of doing things IMHO
  1 - integrate input devices into NEWT input event handling,
      the implementation may be 'native' or using a 3rd party API layer (jinput, ..)

  2 - use a 3rd party API layer

In regards to (1), I could see the joystick/gamepad input device being mapped
as a mouse pointer with many buttons, since we now support multiple pointers.
It's implementation may be native or we could use a (well supported) 3rd party
Java implementation. I guess the problem here is the wording 'well supported' :)

How hard can it be to receive the joystick/gamepad data ?
If one could provide some native code snippets, I would be more than glad
to funnel it in the NEWT event dispatching mechanism.
IMHO these events will just being passed
to the NEWT window owning the input focus, done.


++

In regards to (2) and also for a more broad reflection of input mechanisms
we may need to review the API's you have mentioned.

> What are the viable alternatives to DirectInput/XInput on Windows?
> StreamInput?
>
> In my humble opinion, StreamInput is the only possibility, the traditional
> Windows event loop might not be fast enough for this and... I prefer relying
> on open source APIs ;)

http://www.khronos.org/streaminput/

Well, IMHO streaminput is a novel academic disccusion of semantic input facilities,
ie. face recognition, geometric processing, etc.

OFC, it will become a target one day and maybe the time is right
to jump on the train and participate and generating a binding.
Such binding may require OpenCL and OpenCV. The latter is would be a good start,
being implemented partially with OpenCL. AFAIK somebody did exactly this somewhere
(forgot the URL).

And then again, somehow those input facilities may need to end up
in events being send via the NEWT event dispatcher.
We could easily use generic events for such purpose, where the receiver will
cast it to the expected tagged type, eg. a StreamInput.FaceShowsUp event :)
This will be sweet thing (coming some time soon) for sure.

>
>
> Would it be difficult to adapt JInput to be built with GlueGen?
>
> Is the use of JInput as a starting point a good idea whereas it does not use
> StreamInput?

For sure all good ideas.

IMHO the fasted way to just get joystick and gamepad going
is the above mentioned one (1).
So anybody pls .. I would need your expertise for such native input APIs
and maybe a few native code examples. THANK YOU.


>
> Best regards.


~Sven

On 09/10/2011 12:35 PM, Sven Gothel [via jogamp] wrote:
>
> For sure all good ideas.
>
> IMHO the fasted way to just get joystick and gamepad going
> is the above mentioned one (1).
> So anybody pls .. I would need your expertise for such native input APIs
> and maybe a few native code examples. THANK YOU.

pushing controller state directly into the event dispatcher could be a
nice feature, however it wouldn't be that useful for many realtime
applications (games etc). Usually you would like to have three things:
  - a proper controller abstraction (.listControllers(),
controller.getAxisX() etc)
  - a polling mechanism to receive all events which happened while the
engine was rendering the frame
  - sometimes you even don't care about the event history, all you want
is the current state of the controller. e.g. joystic.throttle.value

jinput solves this quite nicely, you can poll each Axis of a mouse,
joystic etc. On linux its a bit problematic since the application has
usually no read access to the /dev/input files, however in this case you
can let jinput use the awt fallback which gives you at least kb and mouse.

so basically what Julien suggested would be most "effective" IMO. A
jinput plugin which uses newt as fallback instead of awt (to workaround
the /dev/input issue).

(and there is also output for force feedback controllers)

regards,
michael


>
>
> >
> > Best regards.
>
>
> ~Sven
>

On Saturday, September 10, 2011 04:49:00 PM Michael Bien [via jogamp] wrote:
this is not in contrast to my previous post.

as I have mentioned we may either use a 3rd party API or a self written backend.

even if we notify NEWT input listeners with events from such 3rd party API,
this doesn't mean to take away control or details.

the means of event delivery and real time (RT) requirements might
need to be discussed for sure. Currently events may take up to 50ms to be delivered,
and the polling lag plays its part as well.

>
> jinput solves this quite nicely, you can poll each Axis of a mouse,
> joystic etc. On linux its a bit problematic since the application has
> usually no read access to the /dev/input files, however in this case you
> can let jinput use the awt fallback which gives you at least kb and mouse.
>

- polling vs event driven will be one issue (RT issue)

> so basically what Julien suggested would be most "effective" IMO. A
> jinput plugin which uses newt as fallback instead of awt (to workaround
> the /dev/input issue).

- for sure we need an implementation w/o AWT

>
> (and there is also output for force feedback controllers)

good point, yes, seems like they are output devices as well.
for sure this won't fit into NEWT's InputEvent :)

the Q is: jinput -> NEWT, or vice versa

in contrast of using many 3rd party APIs, using a NEWT unified API might
have it's benefits though, if no well maintained obiquitous API is available.

In the end, the idea of NEWT is to provide a platform and vendor agnostic API
for native windowing systems, just another windowing TK.

It's good that we discuss the issue of how it can satisfy input device requirements
going beyond the trivial mouse/keyboard setting.

However we do it, it would be great if one - maybe Julien, starts some evaluation process.

~Sven

>
> regards,
> michael
>
>

/dev/input/js and co. can be accessed on a lot of Linux distros by default, I use a Gamecube pad on Mageia Linux 1 and I don't have to tinker the read access. However, it is quite different for keyboards and mice; in this case, I would like to use NEWT and nothing else.

Currently I'm working on both this and another port of Ardor3D to JOGL 2.