Making Joystick support optional ?
Monkey Targets Forums/Desktop/Making Joystick support optional ?
| ||
| I have conflicting feelings about the way that Monkey currently handles joysticks. It is quite pain-less for xbox360 and ps3 gamepads (except for the d-pad, but that's a completely different story) and I love that, because those are probably what most hardcore PC gamers use... but it's REALLY messy if you want to add support for generic gamepads or joysticks other than the 3 particular devices that Monkey internally supports in Desktop platforms. I know that monkey reads ALL the buttons and keep track of their state, and I already wrote here about that (http://www.monkey-x.com/Community/posts.php?topic=8718), and while that allows me to read all the buttons in a "generic" way (button 0, button 1, etc) the problem is that Monkey also swaps some buttons depending on the "type" of gamepad detected (which is based solely on the number of buttons reported by GLFW). This arbitrary reordering of the buttons makes impossible for me to reliably use non-GLFW functions to enhance the joystick support, or even tell the player to press a given button based on its number as it appears in the config panel (because there's a chance that "button 1" is actually being read as "button 3" after Monkey swaps them). Because of this, in order to reliably "map" the buttons as they are detected by the system, and give universal support to all kinds of joysticks, I have to re-read all the buttons by hand with GLFW calls, and keep track of their state myself. Which means that joysticks are currently being read twice: First by Monkey and then by my code, and that's kinda awful. As the main focus of Monkey seems to be supporting xbox360 and ps3 controllers I don't think that dropping the current remapping and the nice JOY_yyy constants is an option. Perhaps having a flag or preprocessor directive that tells Monkey that I want to handle the joystick myself would probably be the less "invasive" approach for people who want "under the hood" access to the devices (like me). Or perhaps a flag that prevent the button remapping (but that would mess up Monkey's JOY_yyy constants so it's probably not a good idea). I'd love to hear what other people think about this too. I'm sure I'm not the only one struggling with this issue. Monkey does a great job making things easier, but with the joysticks all the code to have universal support is there, it's just lost under some additional remappings and stuff that -in their attempt to improve the support for 2 or 3 devices- makes things quite messy for the rest. |
| ||
| you can use something to rebind your inputs: https://github.com/nobuyukinyuu/SimpleInput I've been meaning to relicense this more freely but..... |
| ||
| If I understand your code, you are using KeyDown to check the button states polled by Monkey right? If that's the case your code will still get the buttons re-mapped by the Monkey code. :/ |
| ||
| yes, they will be remapped. You can set sane defaults yourself, although of course it will still be "mixed up" if a different type of controller is plugged in. However, the user will be able to rebind the buttons themselves. Alternatively, you can offer keybind profiles for the types of controllers you are expecting. The code is agnostic to the type of button state used -- it doesn't even need to be an intrinsic monkey function -- the default ControllerButton uses KeyDown() to detect if I remember correctly, but it includes another type to show you how it's done for situations mojo doesn't support perfectly, in the case of the example, analog trigger inputs. |
| ||
| It looks like a great system, but I already have a re-binding/mapping system in place in my game. It's the low-level button reading what I'm struggling with (and currently forced to do on my own apart from Monkey because of the mixed up buttons). I show the buttons as "Button 1", "Button 2", etc and I want THAT to correlate with what the joystick config panel shows. In addition I also use some non-glfw calls to determine which buttons are NOT POV-Hats and should be ignored, and those functions also need the buttons to be properly indexed. |
| ||
| So, if I understand this thread correctly (Which I probably don't), you want Mark's and/or GLFW's remapping code to be optional? Because, from what I remember, that was added to make things more consistent. Also, plenty of games don't bother being consistent with the control panel. It's not the end of the world. Technically, you could just use names like A, B, X, and Y, and it wouldn't matter. The fact is, most people are using XInput controllers these days. WinMM is just used by GLFW (Unless something changed) for maximum compatibility. Mark's mappings should work as expected on effectively every XInput controller. Case in point, the Xbox 360 controller works exactly how the constants predict. I think you're worrying a bit too much about this. That being said, I do agree that these checks should probably be optional. I'm not actually sure about the history of those extra files (They could be GLFW2-only for all I know). Either way, that might be what's giving you headaches. I personally like Mark's attempts at making button mapping more consistent, so making it an option to disable it wouldn't bother me (Just as long as it isn't removed). |
| ||
| You understood pretty well. I know the remapping is being made for consistency. That's why I said it works really GREAT for achieving consistent access to xbox 360 / PS3 controllers (and that probably extends to any xinput controllers as you said). And I know there's plenty of games that don't bother with being consistent with the control panel, but I'm more worried about getting consistent readings across all my gamepads so I can use other APIs to add support for things like POV hats and stuff. And for that I need the buttons to be reported exactly as they appear in the control panel. Since I DO believe that the internal remapping is doing an awesome job for those who only want xinput support and little more, my suggestion was making either the entire joystick-reading optional, or just the button/axis remapping. But definitely NOT removing it. That would be a great disservice to what's been achieved so far. |
   |