The data type used for identifying key/butt press

Engines, Libraries and Tools JInput
#41

Try now ;D

Endolf

#42

Yeah much better now but there is still a problem:
I think the Axis.Identifier class should be used as a typesafe enum and therefore you should not create any instances of it. Instead the existing instances have to be mapped.
Currently there is no benefit by calling someAxis.getIdentifier() because its name is the same as someAxis.getName() and a comparison with any Axis.Identifier instance will fail.

(The same problem applies to the MacOS implementation of the mouse!)

Btw: I find the linux plugin is in a very good state. Especially the native code is clearly separated from the Java code. I know that it is harder to write the Windows version because of DirectInput’s nasty callbacks but even there ‘business code’ should really live only in ONE world. And I think we all know which is the better one :smiley:

#43

Ok, type safe enums are a 1.5 feature arn’t they?, and thats still beta, I know jinput requires a 2.6 kernel for some features, but requiring everyone to have 1.5 isn’t an option yet, not for something like that.

The axis identifiers being equal might need to be updated, right now I have another sigsegv to fix, so it’s far more important :), raise an issue on jinput.dev.java.net to remind me :slight_smile:

Cheers

Endolf

#44

err no … as of <1.5 typesafe enums are like a design pattern.
To achieve type-safeness one declares a private constructor and then creates some public final instances with it:


public class TypeSafe {
   public final TypeSafe CONSTANT1 = new TypeSafe();
   public final TypeSafe CONSTANT2 = new TypeSafe();

   private TypeSafe(){
   }
}

This is a minimal example. But as you can see that Axis.Identifier uses exactly this pattern (but I wonder why the constructor is ‘protected’).

And btw Typesafe enums in 1.5 are internally much the same as this.

reported this as a bug

#45

I looked at StandardKeyboard.java to see how Axis.Identifier is used there and in the hope to find a confirmation of what I thought the class is used for but did not find that and now I am confused:

Why does Axis.Identifier declares some constant instances which invite everyone to do ‘==’-like checking and is then subclassed and instantiated everywhere?

Non constant and subclassed Axis.Identifier instances are completely useless because they provide mostly the same information like the axis which they belong to?

And now the really confusing part: The constant instances of Axis.Identifier are only (and only there) used from the DX8 plugin’s native code!

Can someone sheer me up with some good news?

#46

Amazing!
After wakeup I finally got it. Now I know what Axis.Identifier is meant to be. Look up this thread’s topic: Axis.Identifier wanted to be the answer.

It could not achieve that goal because some implementations broke the rule of uniqueness of the name of an Axis.Identifier (and subclasses) instance.
Eg: the linux plugin gives the name ‘unknown’ to all Axis-objects and its identifiers.

having said that:
When I first got my hands on JInput I generated the Javadoc and simply guessed how to use certain things of the library. These static constant instances of Axis.Identifier called X, Y, RX, RY etc. looked truly like a nice method of getting the actual Axis type. And for the DirectInput plugin this is true! All buttons on my gamepad get the same instance of Axis.Identifier. If I want to write an application that needed to select the first button it can find programmatically it would simply search for the first controller which is a GAMEPAD or STICK and then use Axis.Identifier.BUTTON to find some buttons.

So in conclusion we have the following:
a) once in a time Axis.Identifier was meant as an AxisType-identifier
b) after that time someone thought it would be the way to reidentify a certain Axis (Axis.Identifier’s name could be saved to disk …)

but neither a) nor b) are implemented consistly and there is a need for both!

Any comments on this?

#47

Hi
Before any changes are made on this I’d like to get some input from Jeff.

Cheers

Endolf

#48

Well, I thought this would start a little discussion …
I am very interested in what other people think about that.

#49

ahem. any news on that?

#50

Jeff seems kinda busy atm, so not got any responce yet

Endolf

#51

I am INCREDIBLY busy right now, sorry guys.

From my memory I think you teo have doped it otu pretty well. (Keep in mind that I inehrited that original code myself :wink: )

I’d say if you both agree then go for it! Thsi sia community owned API after all.

If theres a disagrement and you want me to mediate then tell me and ill dig back into the code and come up with a half-assed opinion :slight_smile:

#52

Ok… well do we have a unique identifier for an axis? We need one, don’t we? And that must be separate from a displayable name, right? I wish I had time to get back into this… argh… I need to write some code that actually uses JInput so I can see where all the confusing bits are.

#53

Hi
Right, I think we need both, a unique ID for an axis, and also a type, that is a constant across platforms and instances of that axis. I don’t have access to the code right now, but I’ll take a look tonight and tomorrow and see what I come up with, does anyone else (TheBohemian/swpalmer) have any suggests?

Cheers

Endolf

#54

nice. things start moving :slight_smile:

for Axis.Type (and I suppose to do this with inner classes like Controller.Type):
We need to find a number of types which can be reliably detected on all platforms. Some answers can be found in Axis.Identifier.

for Axis.Identifier:
Do it like endolf did? That means every plugin has its own mechanism of creating identifiers or can we find a way to let JInput create them*?

And some other questions regarding identifiers:
Are they supposed to be device-unique or truly (at least for this machine) unique?
What kind of information do they want to give us (eg. Keyboard keys) ?

  • that may mean:
    Controller (or better AbstractController) has static method like getIdentifier(Controller.Type, Axis.Type, int index). This can then be used by plugin developers to get (device-unique) identifiers for their Axis instances and application developers may use the method to find a single Axis instance.
    eg. find the 20th button on the gamepad:
    ctl.getAxis(Controller.getIdentifier(Controller.Type.GAMEPAD, Axis.Type.BUTTON, 19));

(Results with the subcontroller thing have to be discussed.)

Only suggestions I am prepared for critics :slight_smile:

#55

Is it just me, or does having a Axis.Type field smell bad? Should we not use a derived class to determine the Axis type? Which of course could add methods appropriate for the type. All of them descending from the root Axis class of course.