Core API changes for Axis.Identifier are looking like they will be going in to CVS soon, that means the work breaks if you are on OSX (any OSX devs out there?? ). Linux and DX plugins should be done, so you will need to get all of them. I'll post back when i'm about to commit, and again when I do commit.

Component.Identifier should not be extended unless you have specific devices you are writting for, and then it would be better to update the core one. There are identifiers listed for buttons, axis and keys, please use them rather than your own . It means that all the plugins will be consistant. There are lots more buttons especially defined now.

I'm against the change. Axis is a proper term for buttons (including keyboard keys), and analog controls. Component is already overused in the JRE. This rename isn't useful and in fact makes things worse.

Axis is a proper term for buttons (including keyboard keys), and analog controls.

How so?, a keyboard has no axis, it has keys. A mouse has 2,3 or 4 (I've not seen any more) axis, it also has a number of buttons. I don't think calling a button an axis is correct.

Quote

Component is already overused in the JRE. This rename isn't useful and in fact makes things worse.

It's a component of the controller. It seemed better than 'bit', 'thing', 'whatsit' or 'ingredient'. The HID standards were mentioned to name it Control, but a controller with controlls *would* have been confusing, as you pointed out. I'd be happy to rename it if something better was suggested. I'm not sure how it makes things worse. Purley because there is already a Component class defined in AWT?. I'm trying to see the issue here, but I can't seem to get what you are saying.

It's a component of the controller. It seemed better than 'bit', 'thing', 'whatsit' or 'ingredient'. The HID standards were mentioned to name it Control, but a controller with controlls *would* have been confusing, as you pointed out.Endolf

For one a Control may have more than one Axis (e.g. X and Y on a stick), you do not treat them as separate controls, but they are separate Axis.

Perhaps Controller is over used in that it is used to group controls on a single device, so there are Controllers and sub-Controllers?

Maybe we needInputDevicewhich has Controlswhich have Axis

?

But the more I think about it the more it seems that the original way is correct. Buttons ARE Axis, knobs are Axis, sliders are Axis, all of these are on a Controller. Though sometimes Axis are grouped (stick with X & Y, flight yoke with X,Y & Z), a general grouping of sub-controllers to accommodate this seems reasonable.

JInput doesn't call an button/key an axis, the Axis class has already been renamed Component. We have Controllers and Components. Whilst I agree that an axis is a control, and so is a key, Controller that has Controls would be confusing. The trouble with calling it InputDevice is that a force feedback gamepad for example is not just Input. What is the proper collective term for all Axis, buttons and keys?, it's certainly not Axis, hence it was renamed. Part of the reason JInput is more complicated is that it was not designed purely for joysticks. It was designed for input. Thats my understanding anyway. Otherwise there would be 3 classes, joystick, mouse and keyboard. JInput already supports digitisers for example.

Ouch, but ok, hmm, I can see how a joysticks X, Y, or throttle axis are there, but, erm, a key doesn't rotate. I *suppose* a key/button goes up and down on an axis, and that line could be thought of as one, but it seems like stretching the definition to me.

On the other hand, if the bigest concern is what we call the things on a controller, then JInput can't be all that bad

hmm, I can see how a joysticks X, Y, or throttle axis are there, but, erm, a key doesn't rotate.

Neither does the joystick. The axes are simply used to form a coordinate system to measure the state of the device. For buttons there is one Axis.

Imagine a button that is sensitive to pressure - such as an USB music keyboard. Now the state of that button not just 0 or 1, as measured on the button's axis, but some other number within a range.

Quote

I *suppose* a key/button goes up and down on an axis, and that line could be thought of as one, but it seems like stretching the definition to me.

I think of it as generalizing... which is exactly the sort of thing that the base class Axis is - a general representation of an input. I realize that it is not what you would typically think of, but I think the generalization applies well to all input types.

Quote

On the other hand, if the bigest concern is what we call the things on a controller, then JInput can't be all that bad

Yeah, point taken, I just thought it odd that it was something that you thought needed changing, and the alternatives proposed seemed to all make more assumptions about the role of Axis.

Yes it is!!!Seriously get a dictionary. The term axis fits. Think in mathematical terms... x,y axis for sticks, a single axis for one-dimensional controls like buttons and keys, or knobs, etc.

Think of inputs on a controller in terms of coordinate systems and the state of the device. Each button or stick adds axis to the coordinate system.

I can see that an Axis is "not bad" in it's mathematical defintion; however, I see the following problems:

- the common definition explicitly mentions it as a rotational reference-line (c.f. http://dictionary.reference.com/search?q=axis - not a "perfect" dictionary, but a good HCF of people's common definitions). Hence a lot of people are likely to expect axes to be rotational .

- "axis" and "axes" are difficult words for english people the pronunciation is similar enough to be damn confusing in speech (easy to mistake one for the other) and it's sufficiently rarely used outside of co-ordinate-space axes that a lot of people probably double-take when they read it and have to think about what it means

Personally, although I've got a sneaking suspicion there's a similar word that more accurately describes the meaning, I'd rather like an "InputDevice" to contain one or more "Input"s (aka "Axis's"). That also makes it clear that they input data rather than output it (c.f. force-feedback devices).

...and I can write "input's" (referring to the programmatic plural of input without impying a different class name) and have it look less stupid than "axis's" (which is IMHO the correct plural of a class named "axis" but looks and sounds horrid).

A "Controller" with Input's sounds equally good to me too .

As to whether "InputDevice" is good or bad for force-feedbacks, I see a force-feedback device conceptually as "implements InputDevice, OutputDevice" - just because it happens to output stuff doesn't affect the fact that it is a fully valid InputDevice *as well*.

InputDevice compared to Controller? Well...three things:

1. Both are pretty obvious (unlike the other areas of contention, I think either would be acceptable - but it depends on your personal profesisonal / programming background; c.f. next points)

2. I slightly prefer InputDevice (as many others would) because I see it *so* often in my OS (linux: you have XFree86 configuration uses "InputDevice" and you see it a lot in linux-USB docs, config, drivers, etc - probably influenced by the X11 name) *and* because when I browse the javadocs for an API called "JInput" without a decent package.html telling me where to start, the "InputDevice" is going to jump out at me as a starting point because of the prefix-similarity with the API name. This is a small thing, but otherwise I'd have been equally happy with Controller, and this just gives it a small edge!

I *think* "Input-device" is often also used in USB manufacturers manuals - ISTR Wacom refers to their own hardware this way.

3. ...everyone's been calling console thingies "controllers" for years and years.

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