next »

[Mathias 'cylab' Henze]

I am currently looking into integration of game controller into hial/xith. While podering the task I am unsure, if it would not be the best to just use JInput as is and skip hial alltogether? What do you think? What would be the benefits of having hial as abstraction while JInput is an abstraction/plugin framework itself and also does keyboard and mouse input?

[Marvin Fröhlich]

I object abandoning HIAL, since we don't have a direct influence to the API and HIAL is very well integrated in Xith and switching to direct JInput would mean an unnecessary API change. API changes are definitely ok, if they improve anything, which isn't the case here. If someone discovers a better API than JInput, which we sould want to use, we would have to change the API again. See, there's a reason, why we have XPAL as a physics abstraction, since the Xith API is not tied to any specific physics lib this way. I would also want to have an abstraction of the net-API, that we will want to use, no matter which we sill decide to use. We will always be free to use a different one without forcing the users to change their coding. Well, you know the basic reasons for abstraction .

I would say, JInput should be abstracted through HIAL just as AWT and LWJGL currently are. I wouldn't have a problem with using the JInput abstraction only, since AWT is very bad for games and LWJGL input events are only fired when the Display.update() method is invoked, which (very rarely) is a problem.

Marvin

[Mathias 'cylab' Henze]

If someone discovers a better API than JInput, which we sould want to use, we would have to change the API again.

I don't see this happen for two reasons. First there is little rocket science involved in input handling and second jinput is an extendable API for which plugins can be written to integrate new devices.

There seems little point in wrapping a wrapper and since hial is also an external library itself (ok, with dev access...) there seems little difference between hial and jinput from a system designers perspective. A game controller abstraction in hial would merely be a copy of the jinput api with different package names.

I can agree to the API change argument, but I don't think this would be a big issue. My suggestion would be to integrate event dispatching like it is now directly into xith and use the device model and data types from jinput.

Well, you know the basic reasons for abstraction .

Well you know, I do software engineering for living

I don't want to push anything here, just inspire a honest discussion to ponder the options...

[Marvin Fröhlich]

I can agree to the API change argument, but I don't think this would be a big issue. My suggestion would be to integrate event dispatching like it is now directly into xith and use the device model and data types from jinput.

This is ok.

But there's one issue to check first. I tried JInput two times. The first time is about three years ago and the second time is about 1,5 years ago. When I first tried it, it was unusable on Linux, since I had to manually change right-bits on the device nodes in the dev-filesystem, which required root rights. This is NOT acceptable. When I tried it the second time, I asked the JInput devs, if this issue was solved and they said, it was. But actually I got the same issues again.

So, if this issue still exists, the API is unusable on Linux and we cannot use it for Xith. Could you please check that? I am willing to try a testcase, if you create one. I currently don't have the time to create one on my own.

Does JInput have classes similar to KeyCode and MouseCode?

Marvin

[Mathias 'cylab' Henze]

But there's one issue to check first. I tried JInput two times. The first time is about three years ago and the second time is about 1,5 years ago. When I first tried it, it was unusable on Linux, since I had to manually change right-bits on the device nodes in the dev-filesystem, which required root rights. This is NOT acceptable.

I fully agree, if it does not work flawlessly with our current target platforms, thinks should stay as they are. Can you describe the issue in more detail? What symptoms did you experience? Did it affect jinput as a whole including mouse and keyboard handling or did it only affect the game controllers?

Suggestions, what the testcase should look like, what functionality it should test?

Does JInput have classes similar to KeyCode and MouseCode?

There is something similar called "Identifier" which is used to identify axes, buttons and keys:
http://www.newdawnsoftware.com/resources/jinput/apidocs/net/java/games/input/Component.Identifier.Key.html

[Marvin Fröhlich]

Can you describe the issue in more detail? What symptoms did you experience? Did it affect jinput as a whole including mouse and keyboard handling or did it only affect the game controllers?

Well, it's long ago . But IIRC I didn't get anything to run including Mouse and Keyboard without manually manipulating the device nodes.

Suggestions, what the testcase should look like, what functionality it should test?

It should try to instantiate and poll Mouse and Keyboard states. the Mouse should be checked absolutely and relatively. The Keyboard should be polled for key pressed, released and typed events.

There is something similar called "Identifier" which is used to identify axes, buttons and keys:
http://www.newdawnsoftware.com/resources/jinput/apidocs/net/java/games/input/Component.Identifier.Key.html

Looks promising. Though there's a method missing, that retrieves a key name string from a key constant. Maybe we should try to get CVS dev access to add stuff like that.

Is there a way to get key typed events (for printable chars)?

Marvin

[Mathias 'cylab' Henze]

It should try to instantiate and poll Mouse and Keyboard states. the Mouse should be checked absolutely and relatively. The Keyboard should be polled for key pressed, released and typed events.

OK, I'll see what I can do.

Looks promising. Though there's a method missing, that retrieves a key name string from a key constant. Maybe we should try to get CVS dev access to add stuff like that.

It's a bit different in jinput. The Identifier is a unique key to one of a device's component. Each key is treated as a component and has a human readable name, so you can display the name of the component, for displaying the pressed key (I assume that's what you are after). Regarding the CVS access... I can imagine that endolf would welcome a helping hand if we really need changes.

Is there a way to get key typed events (for printable chars)?

Haven't looked into the Event classes of JInput... just used polling so far. Maybe we have to wrap this into Events ourselves.

[Marvin Fröhlich]

It's a bit different in jinput. The Identifier is a unique key to one of a device's component. Each key is treated as a component and has a human readable name, so you can display the name of the component, for displaying the pressed key (I assume that's what you are after).

This is exactly, what I meant.

Is there a way to get key typed events (for printable chars)?

Haven't looked into the Event classes of JInput... just used polling so far. Maybe we have to wrap this into Events ourselves.

Well, actually querying the polled key's printable char (if any) is what I need. Events are anyway generated on Xith side. Is there a way to query that?

Marvin