Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#76 Joystick buttons should be able to act as joystick directions

future
open
nobody
None
5
2013-04-20
2013-03-31
Fredrick Meunier
No

I suggest that buttons should be allowed to be joystick directions as well as keyboard keys in order to accommodate d-pads on joysticks which are often mapped as buttons to Fuse.

Discussion

1 2 > >> (Page 1 of 2)
  • Sounds good. I have had a look and made a patch.

    BTW, on widget UIs joystick button 2 is hardcoded to show the main menu so it is useless.

     
  • Wow, quick assistance! The change looks good to me code-wise.

    Is it just me or can you not have two active directions at a time with this patch? e.g. I have an Xbox 360 controller, and I map the d-pad buttons to be up/down/left/right. Setting them up as a cursor joystick, I can do up-down-left-right as normal but don't seem to be able to select diagonals, e.g. up-left or up-right?

     
  • I don't have a d-pad mapped as buttons but I'm using XYAB buttons to simulate this. I have not found any problem with diagonals playing with Typhoon 48k (both kempston and cursor).

    Have you tested both SDL and cocoa UIs? The polling mechanism seems different.

    Also, I usually use an external program like jstest-gtk to test the buttons behaviour.

     
  • I've been using the GTK+ UI with the SDL joystick code enabled which uses the polling mechanism as you say. I'll try with the SDL UI tomorrow.

     
  • This is not working on Windows either.

    Win32 UI fails to identify button events when there is a lower button pressed.

    Buttons configured as directions are overriden by axis events even when there are not position changes. If I "mute" axis events all work as expected. I'll have a closer look to the win32 API.

     
  • OK, I got to test with the SDL UI and I think the diagonals are better there, though I am frustrated by the hardcoded button 2 menu mapping that you mention so can't be completely sure.

     
  • OK, I got to test with the SDL UI and I think the diagonals are better there

    Thanks. Summarizing the tests:

    SDL-> Event driven method, works on MacOSX and Linux.
    GTK -> Polling method. Fails on MacOSX but works on Linux.
    win32-> Fails. Event driven method for buttons but movements are polled.

    IMO looks like axes positions could override directions captured from buttons. Maybe we could disable the axes from the preferences window or store the last position of the two axes.

    though I am frustrated by the hardcoded button 2 menu mapping that you mention so can't be completely sure.

    Seems a shortcut for gaming consoles where not exist a keyboard, but WII UI use the HOME button for opening the menu.

     
  • The hardcode of the joystick button 2 to menu for widget UIs came from the time when we were trying to make Fuse a bit nicer for consoles, especially handhelds like the Gizmondo and the GP2X to allow keyboardless operation of the menus. It is frustrating when using the XBox d-pad mapped from buttons to directions though :) It should probably be configurable to something else.

    I think we will always have potential problems when mapping raw presses, releases and axes motions to the same buttons.

    I think we could have some state stored where a key is pressed when none of the keys/joystick/button/axes mapped to it are pressed only rather than have a direct mapping of source key/joy state to destination state.

    e.g. for Spectrum keyboard key 7, the cursor joystick emulating joypad, the up button on a d-pad and the host machine keyboard key 7 could all be sending press/release events to the emulated keyboard. Something would need to track the state of the emulated keyboard and only change the state when all sources are in a non-pressed state. I deal with related issues with the emulation of the PC keyboard symbols ({}|:", PC cursor keys and the like when you press e.g. shift, special key 1, special key 2, then release shift leaving the other two pressed without their related shifts) in Fuse for Mac OS X in fuse/fusepb/keystate.[ch]. A similar approach could work for the buttons in general with a state being stored pre-emulated key/joystick axis direction.

     
  • The hardcode of the joystick button 2 to menu for widget UIs [...]. It is frustrating when using the XBox d-pad mapped from buttons to directions though :) It should probably be configurable to something else.

    As far as I can see, there are two modes of operation:

    • Inside emulation. Probably Fuse should extend configuration options and allow joystick buttons launch emulator commands (open menu, pause emulation, etc). Each console port might pre-configure its pad according to the button layout.

    • Inside menu (widget UI only). Button1/Button2 are hardcoded to enter/leave submenus and accept/cancel operations. D-pad mapped from buttons to directions should not work here as mappings from "emulation mode" are not applied in "menu mode". Probably Fuse should allow changing configuration for this mode.

    I think we could have some state stored where a key is pressed when none of the keys/joystick/button/axes mapped to it are pressed only rather than have a direct mapping of source key/joy state to destination state [...]

    That sounds really interesting, but if I understand correctly, kempston/timex/fuller joysticks are not mapped to spectrum keys so an analog stick would still interfere with the d-pad, isn't it?

     
    • The axes shouldn't interfere if you have the facility to map the axes directions independently to spectrum inputs in the same way as the the d pad button mappings.

      I do think that is probably too much refactoring for 1.1. What do you think?

       
1 2 > >> (Page 1 of 2)