Passing Component down to the Environment

Engines, Libraries and Tools JInput
#1

Hi
Is there a reason why jinput has to be availble on command line apps?, if not, would it be possible to change the spec to allow/force the passing of one or more (java.awt.Component)s down to the enviroment, this would mean I don’t have to use libgii (which is being a pain), it also means the user has control of which (if any) windows get events fired when in focus. It’s portable over all platforms java runs on, and means you would get a consistant behavior. e.g. under direct input once you have access to a device, your window can loose focus and you still receive events, under X once you loose focus it’s gone, no more events (without some very nasty low level code).

Most if not all games are probably single window anyway, and those that arn’t could just pass another Component down.

This is opening the floor to discussion.

Are the JInput team willing to discus this?

Cheers

Endolf

#2

[quote]Hi
Is there a reason why jinput has to be availble on command line apps?, if not, would it be possible to change the spec to allow/force the passing of one or more (java.awt.Component)s down to the enviroment, this would mean I don’t have to use libgii (which is being a pain), it also means the user has control of which (if any) windows get events fired when in focus. It’s portable over all platforms java runs on, and means you would get a consistant behavior. e.g. under direct input once you have access to a device, your window can loose focus and you still receive events, under X once you loose focus it’s gone, no more events (without some very nasty low level code).

Most if not all games are probably single window anyway, and those that arn’t could just pass another Component down.

This is opening the floor to discussion.

Are the JInput team willing to discus this?

Cheers

Endolf
[/quote]
Sure, Im happy to discuss it.

I’d really like to avoid forcing the user to load up and run the entire AWT infrastructure just to get input events. It seems quite wasteful to me as well as needlessly tying ourselves into the overly-complex AWT internals.

Having said that, having an option to tie to a Java frame might be useful. I’d like to think carefully about how it would be done to avoid breaking what we already have.

JK

#3

Does JOGL require the AWT infrastructure?

Kev

#4

Good point, but JInput is not for use exclusively with JOGL… it is possible that it would have advantages over the input in LWJGL, or be used with some other graphics binding entirely.

If AWT is pulled in it should be considered carefully.

I wonder if there could be some way to restrict the reference to AWT stuff, by attaching some sort of context that depends on the plugin. The context could be null, or some other object entirely for other plugins.

#5

[quote]Does JOGL require the AWT infrastructure?

Kev
[/quote]
I think the question here really is “SHOULD JOGL require AWT?”
IMO the answer is no.

I don’t want to propegate and reinforce what I personally see as a weakness, instead I’d like to do “the right thing” and encourage others to do so as well.

I’d love to be able to make such things plug-in options. The trick is finding a clean way to let the app set such options. Currently since plug-in loading is automatic, its not really exposed at run-time :frowning:

#6

I thought that the significant difference between JOGL and LWJGL was the use of AWT? If its not the right thing to do, why has JOGL chosen to do it?

I would have the “the right thing” would have been to clearly defined what the API is intending to do. If its JInput is aimed at games then I would have considers have a window (at least of some sort) mandatory.

Now, whether thats an AWT window or not, well… different matter. Maybe some new level of wrapping needs to be passed down which contains with an AWT window or a native window?

Kev

#7

Hi
I’ve done more digging. It seems as though under linux there are only few options for keybaord control.

1). Using a real terminal (as in sat at the machine, with no X running at all), in this case you seem to be able to get some keyboard input working.

2). stdin, this would work under X, but you can’t tell if a key is held down. you get a key pressed and released event imediatly, then one of each for each tim the keyboard repeat is fired, so you would need some kind of timer thread to work out if the keyboard repeeat time was up, and thus if the key was being held, also the terminal has to be the window in foxus, open up and focus another window (an awt window with a jogl canvas in it for example) and you loose the keyboard focus.

3). Get access to a native window and montior it’s events. this means jinput must have the java.awt.Component to get the details in the jni side of things. You can then get keyboard and mouse events for this window only, if you want to be able to get them whilst another window is in focus, that window too must be passed down and registered in the native level.

I understand that as of kernel 2.5 (unstable branch) and thus as of 2.6 (stable) there will be another way to access the keyboard under linux, that seems perfik. however, thats not yet, and most people I imagine will be running 2.4 kernels still.

Advice/suggestions welcome

Cheers

Endolf

#8

Evening
Ok, i’ve cracked it I think, as long as you have a 2.5 or 2.6 kernel, i’ve played and found that I can do almost mirror the direct input behavior, no need for any windows.
Is it acceptable to require a 2.5 or 2.6 kernel. I must admit that untill I started playing with this, all my boxes were on 2.4 kernels. But i’m guessing linux gamers are the type who will install 2.5 kernels already, and will install 2.6 as soon as it’s not 2.6.0-test1 :slight_smile:
It will require some config. There are some issuse though. It won’t work remotly, so running over an ssh/telnet link won’t work, nor will running over a remote X session. You can get keyaboard input from stdin under a ssh link, but it’s a little more work, and I’m not sure if it’s worth it, is jinput supposed to cope with this or not?

Cheers

Endolf

P.S. got the developer status sorted. Thanks to Jeff

#9

[quote]I thought that the significant difference between JOGL and LWJGL was the use of AWT?
[/quote]
Okay your getting into IMo territory here:

Support of AWT yes is a good thing. It shoudl be possible to use the OGL binding seemlessly with AWT.

REQUIREMENT of AWT, no. Many many games really need no AWT functionality and its VERY memory and load-time wasteful to force the game to load it anyway.

#10

[quote]II would have the “the right thing” would have been to clearly defined what the API is intending to do. If its JInput is aimed at games then I would have considers have a window (at least of some sort) mandatory.
[/quote]
Not necssarily. What if you are on a windowless device like a game console?

In JSR134 we did clearly define the goal, which included game support on devices that ranged from desktop VMs to potentially handhelds and concluded that tying to a window was a bad idea.

Now I wasn’t part of the sub-comittee that designed the API, but as a library architect for many companies in the past (ie Phillips, Crystal Dynamics, etc) I’m going to go on with some philosophy of my own.

IMO

Seperability is a highly desirable trait in a programming library. Conversely interdependance of disperate functionality is a highly undesirable trait. In general there is no reason why input should be tied to output. They use totally different hardrware. Every system I’ve seen that does tie them together (Apollo’s Window manager, X, Win32) greatly complciates the life of the programmer and severly limits the generality of their library.

#11

[quote]Evening
Ok, i’ve cracked it I think, as long as you have a 2.5 or 2.6 kernel, i’ve played and found that I can do almost mirror the direct input behavior, no need for any windows.
[/quote]
FANTASTIC! great work!

I think so. Anyone have a strong reason they disagree?

JK

#12

I believe that is ok, as if we look at what the 2.6 (2.5 is the “unstable” - think windows me :wink: - version of 2.6) kernel got to offer for gaming people, my guess would be that all serious gamers will be using that kernel (or atlest so many that pointing out that the new faboulus game X requires the 2.6 kernel won’t be a problem ;D ).

kernel 2.6 (What I know of it):

  • Preemtible kernel (e.g. better visual feedback/performance)
  • Force-feedback/rumbler support (from another thread here on jg)
  • endolf’s input :slight_smile:

EDIT: 2.6 is in “beta” now btw.

#13

Yeah, it’s a lot easier to require a recent version of Linux. Since upgrading is basically free, I imagine the new versions are adopted by end users faster than other platforms.

#14

Hi
I assumed that linux gamers would run bleeding edge kernels too, but I did a quick poll over at happy penguin to see what kernel the gamers were running and the results weren’t too encouraging, the poll had 4 options, running 2.4., running 2.5., running 2.6.* and will be using a 2.6 as soon as have one for me. only 41% said the latter, I was the only one who said 2.6., no-one admitted to a 2.5. and the other 50% ssaid they were on 2.4.*, which means they won’t jump on 2.6. Admitidly it’s only been running a couple of days and there arn’t that many voters yet. Poll results

Anyway, i’m pondering going direct to the event layer rather than having it wrapped in libgii, libgii hides too many things, and doesn’t really give that much improvemnet over going direct, I still get the benifits that late 2.5 and 2.6 kernels map the keyboard and mouse to this level, so I can still look almost like the direct input version in terms of functionality. There is one bug that I think is a kernel level bug that means my 3 axis, 4 button joystcik plugged into the game port reports it’s throttle axis asa rudder, but I could do a nasty and map it until it’s fixed (i’ve asked about it on the input dev mailing list). So, although it means things are delayed again, I think the end result will be much better for it. And i think it means I can auto detect everything plugged in, with no config at all ;D
The one and only other problem so far is that the keybaord driver returns every key that is possible (so it seems) regardless of wether your keyboard can do it or not (my 102 key UK ps2 keyboard gets reported as having such things as play keys, and volume controls, which it doesn’t), but i don’t think this is too much of a problem, any user will realise they don’t have those buttons so shouldn’t assign them to anything in the games config screen :slight_smile:

Cheers

Endolf

#15

Its awesome that your doing all this legwork, I’m really really grateful the project has you :slight_smile:

On the web poll, keep in mind that web polls are totally unscientific and there is no way to assign an accuracy to them. (This is true of any self-selected sample group such as a web poll.)

JK

#16

[quote]Its awesome that your doing all this legwork, I’m really really grateful the project has you :slight_smile:
[/quote]
Wait till you see it working, leg work is meaningless unless it turns into something useful :slight_smile:

[quote]On the web poll, keep in mind that web polls are totally unscientific and there is no way to assign an accuracy to them. (This is true of any self-selected sample group such as a web poll.)
[/quote]
True. The lack of responce has also made me wonder about the number of linux gamers out there, whilst I’m working on this code i’m not sure i’ll ever use it except to test the stuff I write on top of it. I bet there are large groups like me. On the other hand, the 2.6 kernels are introducing some things that may encourage more gamers to linux, only time will tell.

On the bright side I think the native library is done, working on the java side of it now, fingers crossed for next week.

Cheers

Endolf