Joystick enums and identifiers

[Nexus]

Wouldn't it be more uniform if SFML provided an enum for Joystick buttons like for mouse (sf::Mouse::Button) or keys (sf::Key::Code)? Maybe the enumerators don't carry meaningful names, but at least you would have more type safety than with plain unsigned ints.

I noticed that when I wanted to write an overloaded function for my action event system. The joystick variant is far less expressive:

Code: [Select]

thor::Action keyAction(sf::Key::Y);
thor::Action mouseAction(sf::Mouse::Left);
thor::Action joystickAction(0, 1); // (joystick number, button number)
And the other question: Why do some identifiers contain "Joy" and some "Joystick"? Don't you want to use "Joystick" throughout the library? (Meanwhile, you must hate me for this kind of question )

Code: [Select]

sf::Joy
sf::Event::JoyButton
sf::Event::JoyMove
sf::Input::IsJoystickButtonDown
sf::Input::GetJoystickAxis

[Laurent]

Wouldn't it be more uniform if SFML provided an enum for Joystick buttons like for mouse (sf::Mouse::Button) or keys (sf::Key::Code)? Maybe the enumerators don't carry meaningful names, but at least you would have more type safety than with plain unsigned ints.

I don't think that type safety is important here, a joystick button is just an index. An enum would be like JoyButton0, JoyButton1, ... and people would write complicated code because it wouldn't be clear that JoyButton0 == 0 etc. (or at least, it wouldn't be clear that it's a consistent thing they can rely on).

I noticed that when I wanted to write an overloaded function for my action event system. The joystick variant is far less expressive:

I thing the problem here is not the lack of an enum for joystick buttons, but rather too many implicit things in your API
I see two solutions to your problem:
1. defining your own enum for joystick buttons (they wouldn't be in namespace sf::, though)
2. making things a little more explicit:

Code: [Select]

thor::KeyAction keyAction(sf::Key::Y);
thor::MouseAction mouseAction(sf::Mouse::Left);
thor::JoystickAction joystickAction(0, 1); // (joystick number, button number)

And the other question: Why do some identifiers contain "Joy" and some "Joystick"? Don't you want to use "Joystick" throughout the library? (Meanwhile, you must hate me for this kind of question )

I absolutely hate this :mrgreen:

Using "Joystick" everywhere would of course be more consistent, but it produces really long lines of code

Code: [Select]

if ((event.Type == sf::JoystickMoved) && (event.JoystickMove.JoystickId == 0) && (event.JoystickMove.Axis == sf::Joystick::AxisPOV))
But I guess it's less important than a consistent API.

[Nexus]

But I guess it's less important than a consistent API.

Actually, I just wondered why you decided like this. You might have chosen "Joy" everywhere. But it's still almost consistent, for events you use "Joy" and for realtime input "Joystick". (Don't take this consistency stuff too serious. Sometimes I'm just curious

I see two solutions to your problem

I am currently working on a third solution:

Code: [Select]

struct Joystick
{
Joystick(unsigned int id, unsigned int button)
: Id(id)
, Button(button)
{
}

unsigned int Id;        ///< The joystick number
unsigned int Button;    ///< The joystick button number
};

Joystick Joystick0(unsigned int button);
Joystick Joystick1(unsigned int button);
So, the user code would look like this:

Code: [Select]

actionMap["fire"] = thor::Action(thor::Joystick0(1)) || thor::Action(sf::Key::X);
Do you consider this too ugly? First I also thought about static factory functions like thor::Action::Key(), but the unnecessary length and duplicate information didn't please me. Since thor::Joystick often appears in complex expressions, maybe I will even call the class "Joy" in the end

Another option are two namespaces Joystick0 and Joystick1, in which is an enum with Joy0..JoyN (how many buttons can a joystick have?). Then you would at least get rid of the parentheses.

[Laurent]

I am currently working on a third solution

Looks good, but it's less convenient to use if user has the joystick id in a variable (he must use a switch).
Plus, it's still not clear that 1 is the button index.

how many buttons can a joystick have?

sf::Joy::ButtonCount

[Nexus]

Looks good, but it's less convenient to use if user has the joystick id in a variable (he must use a switch).

Then, he can use the constructor:

Code: [Select]

Joystick(myId, myButton)

sf::Joy::ButtonCount

Thanks. But are there really 8 supported joysticks (sf::Joy::Count)?

Plus, it's still not clear that 1 is the button index.

Thats true... I could also write something like that, maybe along with some helper functions:

Code: [Select]

namespace Joy0 // same with Joy1
{
    const Joystick Button0(0, 0);
    const Joystick Button1(0, 1);
    ...
}

Joy0::Button5;

[Laurent]

This solution looks good too, but don't confuse users with too many helpers

But are there really 8 supported joysticks (sf::Joy::Count)?

There are even more supported joysticks, 8 is an arbitrary number.
There's no limit on Linux (joysticks are files) and MSDN says the max ID is 15 for Windows > NT 4.0. No idea about Mac OS X, joysticks are not supported yet.

[Nexus]

Okay. I could also use arrays

Code: [Select]

thor::Joy[0].Button[5]
or proxies

Code: [Select]

thor::Joy(0).Button(5)
In contrast to namespace constants (following code), the user can pass variables to the id and button number. Plus, no public helpers are necessary

Code: [Select]

thor::Joy0::Button5

[Nexus]

For the moment, I stick to the proxy solution. If it is inconvenient, users will complain

Thanks a lot for your API suggestions, Laurent! And don't worry too much about "Joy" and "Joystick", there are far more important tasks

[Laurent]

And don't worry too much about "Joy" and "Joystick", there are far more important tasks

Yeah, I know :cry:

[DarkGlitch]

Well I for one would like to see a Joystick Hat enum. It would be nice

How would one go about obtaining the index for joy hats?

[Laurent]

There's only one supported hat, and it's called "POV" in SFML.