JInput 2??

Engines, Libraries and Tools JInput
#1

Hi

I have been asked for an event queue based version of jinput, so that the queue can be read and checked for events. Not a positive notification, just a queue for events.

What I am proposing, is that we move a chunk of the functionality up from the native code into the java, and expose an event queue on each device. I’m thinking that each button/axis/key should have a queue, but there must also be a way to clear the queue for events on components that are not being monitored.

I also propose that the existing API should be a wrapper around the queue’s exposed, so no existing JInput app should need any rework, but new apps have the choice to use the event queue.

As event queues as already used in the underlying native APIs I don’t see exposing an event system as being that much of an issue, and wil allow us to common up the code for combining the events on each poll.

My worry is that some platforms (say a console) may not have events, and may only poll. One way round this would be to have an ‘eventQueueSupported()’ type method that can return false and so users would know they needed to poll the device. The other way is to have the underlaying plugin say that it has no event queue, and make a simulated queue with synthetic based off the poll call.

Discuss :slight_smile:

Endolf

#2

Yay! Good idea. :slight_smile:

Don’t worry about “other devices” that don’t support events just yet unless you specifically know of some? Presumably the additional API would allow someone to implement a device that always had an empty event queue but still allowed access to the pollable bits of the device (as with the current API)? So, even if a device in the future doesn’t support events a Plug-in could still be written to expose what is available.

If you choose to use hardware event queues then you run the risk of not supporting some non-generic bits of hardware. The niceity of a eventQueueSupported() method is fine but I guess thats a “return true”; for all current plugins/devices.

Kev

#3

+1

I like it.

#4

Some comments:

  1. I’m with kev regarding devices that doesn’t do events: Don’t expose an isEventQueueSupported unless we actually know of a configuration that doesn’t support events. And even so, I’d prefer some form of emulated event queue to simplify applications.

  2. Regarding the queues: I’m not sure that a queue per axis/button/key is a good idea, since that would potentially remove any relative timing information. For example, it is convenient to know that the mouse moved 10 units in the +x axis, and then the left mouse button was pressed. With a queue on each of the axes, you’d loose that information. Alternatively, you’d need some kind of semi-global timestamp for each event that can be compared between queues.

  • elias
#5

Another thing: Why do mice have to be divided into two sub-controllers? It seems like a complete waste, and will only complicate events since event queues probably have to be attached at the highest level possible (device level) to maintain event ordering information.

  • elias
#6

That was in the reference implementation, I suspect as a demonstration that it was part of the API. I think we should scrap it in v2. Subcontrollers will still be there for devices that present them, but I know of none and we should not fake it in the API for the sake of it.

Endolf

#7

My comments FWIW.

The original API was developed in coperation btw Sun and a Sony PS2 engineer. Event Queue’s are an artifact of complex windowing systems, you wont see one to my knowledge on any console and as I am not willing to give up the dream of being on consoles I wouldn’t want to see them excluded.

While I think a re-design of the udnerside is well in order (I personally dont like the way the plug-ins work, I think theres a lot of needless complexity there) I’d not want to see console compatability lost.

THose are my thoughts.

#8

I don’t agree with the notion that event queues are window system specific complexity (sure, events like “window is activated”, “your app is asked to quit” are definitely window system specific, but we’re not discussing that kind here). As described in the thread

http://www.java-gaming.org/forums/index.php?topic=1731.0

you can easily miss device updates, even with fairly frequent polling. So in my view events are a crucial feature we should support, at least for plugins that allow it (true for all three supported platforms today).

In any case, plugins that don’t support event queues can easily be acomodated by synthesizing events, one event for each poll().

  • elias

P.S. If you want additional evidence that events are important, take a look at the Mac OS X plugin in the case of mice axes. They are relative, but the axis deltas are only queried once per poll() with hid_device->getElementValue(), so mouse moves can be missed:

  1. User moves mouse 20 units to the right, and the value 20 is recorded in the “current” value returned by getElementValue()
  2. User moves mouse another 1 unit to the right and the value 1 is recorded in the “current” value returned by getElementValue()
  3. Jinput polls the x axis and gets the value “1” back, while it should have been “21”.

Note that the only way to fix this is to use event queueing and add up the deltas. Of course, a different API spec for relative axes (add deltas instead of reporting the last delta) would fix this, but the situation is that you need queues on Mac OS X. I’m sure this is the case for some other plugins as well (I seem to remember that endolf adds up deltas from event queues on linux as well). The only controversial change here is that we should expose this queueing to the user, to fix the problem of fast moving axes (esp. digital axes like keys). And since event queueing can be “faked” as described above, I don’t see a reason not to expose it.

#9

Excellent. Me neither.

The point is to expose both events and the existing poll options to the developers.

I want to make it clear that the inclusion of one does not exclude the other.

The plugin will need to expose (to the common JInput bits) wether it is event based or polled, and the higher levels will deal with simulating a poll API for event based plugins, or simulating an event based one for poll based. We are not talking about events and listeners here, you will still need to poll the devices, it just gives you the choice to go off and either get an JInput event list, or to getValue on the components. Both will be there for all plugins regardless of what the underlying implementation does.

Thats my take on it.

Endolf

#10

This sounds like a good idea. In particular I’m definitely in favor of writing more of JInput in Java because it will make experimenting with API designs like this a lot easier.

Would you consider using GlueGen to bind the low-level APIs up to Java? This tool has been made quite a bit more general now that it is being used to generate the JOAL bindings and I think it should be up to the task. I’d be glad to help set this up.

#11

A long as, as a developer, it doesnt force me to either queue when I dont want it queued, or go through a needless inefficiency getting to whateve the native level does then I say go for it.

Oh and elias, you misread me.

I didnt’ say it was an OS specific thing. I said it was an artifcat of complex GUI systems being built into the OS.

Game consoles, whicdh don’t have such complex GUIs at their system API layer, generally don’t have event queues.

That was my entire point.

#12

Thats the point, expose the additional functionality without removing the existing. Both at the same time always. That way the developer gets to pick one, and it will always work.

If the plugin works in polls only, then the API will wrap it so that a developer can if they wish still use events. If the plugin only deals with events, then the API will wrap it so that poll works too. The underlying plugin does what it knows how to do, and with the aid of some helpers, exposes the other way too.

This way a console focused team using a future plugin can use poll, and still port their app to say linux, that at the kernel level, uses events, with no code changes. Also a PC/mac focused team can use events, and if in the future they wish to port to a console that at it’s level uses polls only, then they will not need to make any chances either.

We can also mix things. Example, at the moment, the DX plugin gets the current data for say a joystick, but uses events for mice.

I want to make it clear, that this will mean that any user of jinput can use either method, with any plugin on any platform. The plugin knows how it handles events natively, and with the aid of helpers will expose both ways of doing things.

Full compatability and the user of JInput chooses how to use it.

HTH

Endolf

#13

Yes. A quick glance certainly seems to raise some interest from me :slight_smile:

Endolf

#14

Great. Send me email (kbr at dev java net) when you’re starting the new work. I’ve requested Developer status optimistically, but won’t make any changes until you’ve planned them out and they’ve been agreed on.

#15

Cool.

And yes Id liek to see mreo fo it up in the Java layer as well.

#16

We’ve started to work on it, and should have something ready by next week. We’re cleaning up and completing the mac os x support and we will look at implementing queueing and other features.

  • elias
#17

Btw… in case it wasn’t clear…

I’m not at ALL offended by the urge to improve on JInput. In fact I’m thrilled that you guys care enought about it to want to do this!