Joystick PoV Axes Flipped

[myroidtc]

I'm using SFML 2.1 Visual C++ 11 (2012) - 64 bits and Windows 7.

sf::Joystick::Axis::PovX corresponds to the d-pad vertical instead of the horizontal for me. I've tested with two controllers (DualShock 4 and Xbox 360) and the axis names are consistently flipped. All the other axes are fine.

Is this a bug or are the names arbitrary? Might the OS have something to do with it? It's not that big of a deal, I'm simply curious as to why this might happen.

[Laurent]

Is it the same with other applications, or is it just SFML?

[myroidtc]

It seems to be just SFML. The hat works as expected in the Windows calibration thing and some other applications like JoyToKey and PCSX2 correctly detect the hat direction.

When pressing "up" on the dpad,

sf::Joystick::getAxisPosition(currentJoystick, sf::Joystick::Axis::PovX)

returns -100.0 while "down" returns 100.0. Note that it's PovX and not PovY.

[fallahn]

Ah! Yes, I found this back in April or so when I started working on my current project - and then promptly forgot about it. Just looked at my source and found I'd made a comment about it, so I tried it just now and can confirm pushing left on and X360 DPad returns a negative value on PovY (and vice versa). Am using the current version of SFML from Github on multiple Win 7 machines - although when I started I was probably using a pre 2.0 release. (I tend just just rebuild SFML every few weeks or so when I feel like it, sorry can't be more specific than that)

[NoobsArePeople2]

I can confirm I also have this issue on Windows 8 with SFML 2.0. I compiled from source using mingw.

[wintertime]

I guess I know the root of the problem. This is a proposed fix if you want to try (though its only based on your description above, not on actual knowledge of the used joystick functions):

diff --git a/src/SFML/Window/Win32/JoystickImpl.cpp b/src/SFML/Window/Win32/JoystickImpl.cpp
index c2645e8..7f2bec2 100644
--- a/src/SFML/Window/Win32/JoystickImpl.cpp
+++ b/src/SFML/Window/Win32/JoystickImpl.cpp
@@ -167,8 +167,8 @@ JoystickState JoystickImpl::update()
         if (pos.dwPOV != 0xFFFF)
         {
             float angle = pos.dwPOV / 18000.f * 3.141592654f;
-            state.axes[Joystick::PovX] = std::cos(angle) * 100;
-            state.axes[Joystick::PovY] = std::sin(angle) * 100;
+            state.axes[Joystick::PovX] = std::sin(angle) * 100;
+            state.axes[Joystick::PovY] = std::cos(angle) * 100;
         }
         else
         {
 

[Laurent]

though its only based on your description above, not on actual knowledge of the used joystick functions

So this is a really bad fix

Until we know how pos.dwPOV must be interpreted (which the doc doesn't clearly explains, if I remember correctly), we can't write a proper fix. Your "fix" could work for some cases but not all. For example, instead of switching axes, maybe it's rather a rotation by 90° that must be done.

[wintertime]

They wrote they could use the numbers from the other axis directly, so it would hopefully work. If there is no docs and 3 people write its that way?
I dont have a joystick here for testing and knew I saw that place in the code including your comment about how weird it is to calculate this from an angle (and they did apparently not know the exact place to look), thats why I put the code up for them to try, not for direct including into SFML.

[zsbzsb]

If there is no docs

Fret not, for there is documentation...
.
.
.
.
Welcome to MSDN 

Current position of the point-of-view control. Values for this member are in the range 0 through 35,900. These values represent the angle, in degrees, of each view multiplied by 100.

[Laurent]

There is no doc explaining how to interpret the angle (where is "0", is it clockwise or counter clockwise).

[Jebbs]

Is it not safe to assume that it is the same as a unit circle?

[zsbzsb]

There is no doc explaining how to interpret the angle (where is "0", is it clockwise or counter clockwise).

Actually I just looked at this again and there is what we need. Take a look at the remarks section near the bottom (of the article I linked above).

Most devices with a point-of-view control have only five positions. When the JOY_RETURNPOV flag is set, these positions are reported by using the following constants:

So according to this we should set that flag in the initialize function...

joyInfo.dwFlags =  JOY_RETURNPOV;

Then the returned angle should be constrained to the following quote. And as you can see 0 degrees is up/forward while 90 degrees is to the right. Therefore switching the sin/cos calls around should fix the issue.

JOY_POVBACKWARD   Point-of-view hat is pressed backward. The value 18,000 represents an orientation of 180.00 degrees (to the rear).

JOY_POVCENTERED   Point-of-view hat is in the neutral position. The value -1 means the point-of-view hat has no angle to report.

JOY_POVFORWARD   Point-of-view hat is pressed forward. The value 0 represents an orientation of 0.00 degrees (straight ahead).

JOY_POVLEFT   Point-of-view hat is being pressed to the left. The value 27,000 represents an orientation of 270.00 degrees (90.00 degrees to the left).

JOY_POVRIGHT   Point-of-view hat is pressed to the right. The value 9,000 represents an orientation of 90.00 degrees (to the right).

[Laurent]

So according to this we should set that flag in the initialize function

That would limit the output to 4 directions while we currently have the full [0 .. 360] range.

And as you can see 0 degrees is up/forward while 90 degrees is to the right. Therefore switching the sin/cos calls around should fix the issue.

Right, these indications should be enough to verify the formula.

[zsbzsb]

That would limit the output to 4 directions while we currently have the full [0 .. 360] range.

Well that isn't the way I understood it 

[Laurent]

What did you understand?