Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - CopyConstructor

Pages: [1]
1
Window / Re: Bug in Window/Win32/JoystickImpl.cpp
« on: February 26, 2016, 02:43:20 pm »
You misunderstood me.
I have no problem to use Joystick::Axis::PovX the way SFML implements it.

I am only wondering why the POV is implemented as Axis.
You are right, I don't know the Linux AP., I'm Windows Programmer from the first hour, so please be understanding: The only reason I see for using POV Buttons as Axis is, "because Linux does so".
Maybe in Linux APi the distinction between POV/non POV Axis is a problem?

Since the 1980's, I've seen really a lot of different Joysticks. All of them used
4 to 8 micro switches for the 4 - 8 different POV "directions" - if they had a POV control.

Many games are using these "directions" as simple buttons to "extend" the number of joystick buttons. In Hardware, they *are* switches ordered in in 4 or  8 "directions" -  On this background, implementing them as axis sounds strange to me.

Look at the Microsoft Windows API: There are already constants for the 4 main directions (joystickapi.h)
JOY_POVFORWARD
JOY_POVRIGHT
JOY_POVBACKWARD
JOY_POVLEFT

( The opposed: Seeing the POV as "normal" key's is also wrong, since they are ordered in directions and
normal joystick keys do not give a indication about their position. )
So: I still think the Microsoft approach is better.

Btw.: I'm also no Player (any more) (when I was young, I was).

2
Window / Re: Bug in Window/Win32/JoystickImpl.cpp
« on: February 25, 2016, 06:53:19 pm »
I know it's hard to accept when "your babe" is criticized from a unknown person.  I understand your point of view.

And I Agree, it is not a bug:  but it's neither a feature.

You don't answered my two concrete questions:

Quote
Are there Joysticks, where the POV is analog?
Quote
Why not use them in a switch statement and return accurate values too instead of dealing with sin/cos  and floating point inaccuracy?

3
Window / Re: Bug in Window/Win32/JoystickImpl.cpp
« on: February 25, 2016, 02:17:37 pm »
Quote
This value is zero (-4e-6 is 0.000004), with the inaccuracy of the analog stick and/or floating point numbers.

Ok, I see this value should be zero.
But  that's the Problem! The POV is digital (at least my one).

If a consumer want's to deal with POV (direction) pressed/not pressed, he has to deal with floating point    inaccuracy. It's slower and not very intuitive (with digital buttons).

And, above all, the windows API returns accurate values. Why not use them in a switch statement and return accurate values too instead of dealing with sin/cos  and floating point inaccuracy?
Or the other way: Are there Joysticks, where the POV is analog? I have 4 different joysticks here, from cheap to expensive and none of them have analog POV axis.

Quote
If you had read the thread you linked above, you'd have seen that it's just Windows that treats POV as an angle, Linux for example directly decomposes it as X and Y, like SFML does

Have you ever thought about that the Linux implementation can be done better?

I think this is a common issue about: http://www.connexin.net/computer-software-humor-jokes/what-programmers-say.png




4
Window / Re: Bug in Window/Win32/JoystickImpl.cpp
« on: February 25, 2016, 11:43:27 am »
Ok, than: it's a strange design (not to say "bug")

Sorry.. it really makes no sense to set the other angle to a value like -4.37113886e-06
and not reflect it to the documentation.
How do I get the 4 other (diagonal) POV directions? ( upper left, lower right ...)

I will continue to use Microsoft's joyGetPosEx() API and recommend that for other confused users. The original API is much more clear and better documented.
With this implementation of querying the current POV direction, you don't reach your own Philosophy for a Simple easy to use API.

5
Window / Re: Bug in Window/Win32/JoystickImpl.cpp
« on: February 25, 2016, 10:35:46 am »
The "Bug" comment ist misplaced, sorry for that.

For example, I get the following values:

POV to the right:   
povX = 100                       
povY = -4.37113886e-06 

POV to Backwards:
povX = -8.74227771e-06 
povY = -100

how do this values fit to radiants?

And why does is the documentation for:

Joystick::getAxisPosition only say: "Current position of the axis, in range [-100 .. 100] "?
at least for for POV this is not very helpful.
   
I thought I would help you to quick fix this issue, so I made the work and wrote all I knew about it .
Sorry for that - I will never try to help again.

6
Window / Bug in Window/Win32/JoystickImpl.cpp
« on: February 24, 2016, 09:09:08 pm »
Hi,

For me, querying the axis position of the POV is buggy under windows:
 ( Joystick::getAxisPosition(0,Joystick::Axis::PovX) )  it returns strange values.

The reason is located in Window/Win32/JoystickImpl.cpp:

JoystickState JoystickImpl::update()
{
    JOYINFOEX pos;
    pos.dwFlags  = JOY_RETURNX | JOY_RETURNY | JOY_RETURNZ | JOY_RETURNR | JOY_RETURNU | JOY_RETURNV | JOY_RETURNBUTTONS;
    pos.dwFlags |= (m_caps.wCaps & JOYCAPS_POVCTS) ? JOY_RETURNPOVCTS : JOY_RETURNPOV;
    pos.dwSize   = sizeof(JOYINFOEX);
    if (joyGetPosEx(m_index, &pos) == JOYERR_NOERROR)
    {
....    
       // Special case for POV, it is given as an angle
        if (pos.dwPOV != 0xFFFF)
        {
            float angle = pos.dwPOV / 18000.f * 3.141592654f;  //Bug: angle is in *degrees*!
            state.axes[Joystick::PovX] = std::sin(angle) * 100;
            state.axes[Joystick::PovY] = std::cos(angle) * 100;
        }
        else
        {
            state.axes[Joystick::PovX] = 0;
            state.axes[Joystick::PovY] = 0;
        }
  }
...
}
 

The error is pos.dwPOV is in degrees already! (*100)
For me, this degrees either with Flag JOYCAPS_POVCTS or JOY_RETURNPOVCTS.
Only the convertion for range [-100 .. 100] is needed.
( But I would really recommend to use a angle (radiants or degrees) for the POV, all other is not intuitive. )

According to MSDN this is right:

dwPOV
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.
JOY_RETURNPOV   
The dwPOV member contains valid information about the point-of-view control, expressed in discrete units.
JOY_RETURNPOVCTS   
The dwPOV member contains valid information about the point-of-view control expressed in continuous, one-hundredth degree units.

https://msdn.microsoft.com/de-de/library/windows/desktop/dd757112.aspx

My Situation:
Joystick is: Speedlink Phantom Hawk
Driver: default windows 10 driver (nothing additional installed from manufacturer)
OS: Windows 10


Workaround:
Use joyGetPosEx() by your own:
                               
#include <Mmsystem.h>

        JOYINFOEX pos;
        pos.dwFlags = JOY_RETURNPOVCTS;// or  JOY_RETURNPOV give the same: degrees for my stick
        pos.dwSize = sizeof(JOYINFOEX);
        if (joyGetPosEx(JOYSTICK_1, &pos) == JOYERR_NOERROR)
        {
                if (pos.dwPOV != JOY_POV_CENTERED)
                { // use pos.dwPOV
                }
        }
.....

This values are correct for my joystick:
#define JOY_POV_CENTERED                (WORD) -1
#define JOY_POV_FORWARD                 JOY_POVFORWARD
#define JOY_POV_RIGHT_FORWARD   4500
#define JOY_POV_RIGHT                   JOY_POVRIGHT
#define JOY_POV_RIGHT_BACKWARD  13500
#define JOY_POV_BACKWARD                JOY_POVBACKWARD
#define JOY_POV_LEFT_BACKWARD   22500
#define JOY_POV_LEFT                    JOY_POVLEFT
#define JOY_POV_LEFT_FORWARD    31500
 

 
This bug was already noticed 4 Years ago!
Why the hack is this not corrected?

http://fr.sfml-dev.org/forums/index.php?topic=7054.0



Pages: [1]