Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (575)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  JInput 2??  (Read 2720 times)
0 Members and 1 Guest are viewing this topic.
Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Posted 2006-02-06 22:02:55 »

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 Smiley

Endolf

Offline kevglass

JGO Kernel


Medals: 186
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #1 - Posted 2006-02-07 00:15:29 »

Yay! Good idea. Smiley

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

Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #2 - Posted 2006-02-07 02:58:19 »

+1

I like it.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline elias

Senior Duke





« Reply #3 - Posted 2006-02-07 09:01:30 »

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

Offline elias

Senior Duke





« Reply #4 - Posted 2006-02-07 20:11:14 »

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

Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #5 - Posted 2006-02-07 20:24:12 »

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

Offline Jeff

JGO Coder




Got any cats?


« Reply #6 - Posted 2006-02-08 01:52:50 »

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.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline elias

Senior Duke





« Reply #7 - Posted 2006-02-08 08:36:50 »

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.

Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #8 - Posted 2006-02-08 13:22:02 »

I'd not want to see console compatability lost.

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

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #9 - Posted 2006-02-09 08:14:05 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder




Got any cats?


« Reply #10 - Posted 2006-02-09 10:01:25 »

I'd not want to see console compatability lost.

Excellent. Me neither.

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

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.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #11 - Posted 2006-02-09 10:26:54 »

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.

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

Offline endolf

JGO Coder


Medals: 7
Exp: 15 years


Current project release date: sometime in 3003


« Reply #12 - Posted 2006-02-09 10:31:15 »

Would you consider using GlueGen to bind the low-level APIs up to Java?

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

Endolf

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #13 - Posted 2006-02-09 22:21:16 »

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

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.
Offline Jeff

JGO Coder




Got any cats?


« Reply #14 - Posted 2006-02-10 01:32:08 »

Cool.

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


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline elias

Senior Duke





« Reply #15 - Posted 2006-02-10 14:11:52 »

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

Offline Jeff

JGO Coder




Got any cats?


« Reply #16 - Posted 2006-02-11 21:20:14 »

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!


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (33 views)
2014-10-17 03:59:02

Norakomi (25 views)
2014-10-16 15:22:06

Norakomi (24 views)
2014-10-16 15:20:20

lcass (26 views)
2014-10-15 16:18:58

TehJavaDev (50 views)
2014-10-14 00:39:48

TehJavaDev (50 views)
2014-10-14 00:35:47

TehJavaDev (40 views)
2014-10-14 00:32:37

BurntPizza (63 views)
2014-10-11 23:24:42

BurntPizza (36 views)
2014-10-11 23:10:45

BurntPizza (74 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!