> 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
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.
On Saturday, September 10, 2011 04:49:00 PM Michael Bien [via jogamp] wrote: