Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Studio Chat / RawJoystick issues

Author
Message
Globbits
15
Years of Service
User Offline
Joined: 30th Jan 2009
Location: Cambridge
Posted: 15th May 2020 15:54
I'm trying to create a controller mapping system so that (hopefully) most controllers will work with my game. However this is proving to be more difficult that I thought it would be due to weird inconsistencies with how AppGameKit (basic and studio) seem to work.

Example 1 - POV's

GetRawJoystickPOV(1, 0)
will try to read POV 0 from controller 1.
Assuming controller 1 has a POV 0 then this will return either -1 (not pressed) or 0 to 36000 for the direction.
However if controller 1 doesn't have POV 0, then this always returns 0. This is an issue as it then appears as if controller 1 does have a POV 0 that is being pressed up.
The same issue happens for the other POV's 1 to 3.

It would be far better if POV's that don't exist could return -1. This would certainly make things much easier!

Example 2 - Xbox 360 controller on Linux (the controller works fine with AppGameKit on Windows).

The DPad is a real issue as it seems to return values in both GetRawJoystickSlider and GetRawJoystickButtonState at the same time. Therefore any control mapping system would have to be capable of handling multiple inputs for a single action, which seems unnecessarily complex for a game that doesn't have very many controls. This isn't really an issue for the game itself, but more for the mapping system to recognise what input the player wants to assign to what action. Also the GetRawJoystickButtonState is returning the pressed state for two buttons for each direction of the DPad.

Does anyone have any suggestions or similar experiences?
SFSW
21
Years of Service
User Offline
Joined: 9th Oct 2002
Location:
Posted: 15th May 2020 17:59 Edited at: 15th May 2020 18:00
For example 1, the difference can actually help determine if a device has a POV input or not at startup, which you then can treat it as you want to in code (if your goal is an initial auto configuration). For example, after you execute 'CompleteRawJoystickDetection()', run through the available POV commands to determine if any are returning a '-1' indicating they are live. You can then set up a default mapping to one or more to listen to the POV('s), otherwise, you can turn it off by default if it's '0' at startup. If it did return a '-1' at startup even if it didn't exist, then you wouldn't know if it were available or not and you'd need to leave if off by default and have the player enable it manually.

One thing to be aware of though is that DirectInput will often not return any signals from a connected device until a non centered signal is received, so it's possible that with some devices, any axis, POV, or slider input will sit at '0' anyway until an input is moved. As a result, some device may default to no POV anyway even if they have one, but for the ones that are picked up on startup, you could use the '-1'/'0' difference as a way to automatically map controls.

For example 2, device enumeration and usage has always seemed weird on Linux in any control system I've tried to use. You may also notice that device names can return very strange strings. There can be double input signals and mismatched values relative to Windows, so you'll want to account for those in code. They are hopefully pretty consistent from system to system at least, so you should be able to account for them once and find the same behaviors on other Linux systems. I don't know for sure though as I haven't been able to test across different distros and devices much yet. Ultimately though, if you have an input that returns more than one signal, you can simply ignore one in favor of the other. And with a control mapping system, this can also be left up to the player to let them chose which input return they want to map.

But also on that note, part of the challenge with the signals you get with Linux is that the POV inputs depend on those split signals. That is, you must listen to both inputs to determine what angle the POV is actually at. I use this code to determine POV angles listening to 'GetRawJoystickSlider(DevNum,1)' and 'GetRawJoystickPOV(DevNum,0)', with the 'jhatpov[]' array being used to store an integer that selects which angle the POV is at starting with '1' for 'up':



This is currently the only way I know of to retrieve POV data from a device on Linux. Kind of tricky, but hopefully consistent and reliable.
Globbits
15
Years of Service
User Offline
Joined: 30th Jan 2009
Location: Cambridge
Posted: 15th May 2020 22:24
That's very useful information and suggestions, thanks very much. This will help me a lot.

Login to post a reply

Server time is: 2024-03-29 14:11:26
Your offset time is: 2024-03-29 14:11:26