Controller only?
In the past I have used an application called 'ControlMK' to control the mouse with an Xbox 360 controller on Windows 7.
I'd just like to throw in my support for joystick/controller support in the menus. I'm trying to get a controller-only RetroPie mini-console (using an 8Bitdo controller and one of those awesome SNES RetroFlag cases) as a gift and Descent completely from the couch would be pretty awesome inclusion. I might take a look at the code and see if I can help, but I'm very much an amateur.
No promises on when or if this gets implemented, but if you want to help, a great way to start would be to write up a requirements document. From the posts here, I understand that interested users want the game to be usable with just a joystick, without using any other input devices (keyboard, mouse). There is considerable wiggle room in satisfying that generality, and at least some ways of satisfying it probably won't satisfy the people who want to use it. For example:
  • Is it acceptable if you need to use joystick buttons, not axes, to navigate? Axes are analog inputs, so if an axis can be used, then the navigation code is more complex because movement below a certain joystick-specific threshold is noise and needs to be ignored, but movement above that threshold is user action and needs to be handled. Buttons are digital inputs, so we can assume that all button presses are deliberate user action and all button presses should be handled.
  • If button-only is acceptable, how should the end user specify these buttons? Does Rebirth ship with a fixed list and you are required to use those, with no ability to change them without recompiling the game? Does Rebirth load user customizations and, if it does, how does the user enter those customizations? Can we assume the user has a keyboard for entering complex configuration files, but he chooses to use the keyboard only for data entry, not when actually playing the game?
    • If we can make that assumption, then it's easy to say that the user who wants customizations must use the keyboard to change how the buttons map to actions before he can play the game.
    • If we cannot, then we need an in-game interface that can be driven with the default controls and used to create non-default controls. (Full disclosure: I'm not interested in writing such a user interface, so if your requirements document includes requiring an in-game interface, I won't be fulfilling your requirements. Sorry. I'll still consider including it if someone else writes it, though.)
  • Should the navigation be implemented by having the joystick controls act as a proxy for mouse controls (complete with using the joystick to move the on-screen cursor) or is it sufficient that the user can configure the game from the joystick without becoming frustrated with the controls?
Generally, think about what you would put in the instructions on how to use the new feature, and any caveats you would include to users about things that they cannot expect to work as a user might guess. Going with the above example, some users might hear "Works with just a joystick" and expect to use pushing the joystick axis for "Pitch down" to navigate in one direction in the menu, and "Pitch up" to navigate in the other direction. If the joystick-in-menu support is button-only, these users will be disappointed and/or frustrated, so the notes should warn them that this is not supported, and describe how to do it in a supported way.
This is great advice and every question you asked is one I wondered about. I will write up something with my own ideas and scan the comments on this thread for other ideas. I'll throw it on Github and link to it here.

Forum Jump:

Users browsing this thread: 1 Guest(s)