›

No DPAD Events

tacograveyardtacograveyard Posts: 18Member
in ODK (OUYA Developer Kit)
I can access key down events for O, U, Y, A, but none of the dpad directions.

From what I read, I should be checking with:

OuyaController c = OuyaController.getControllerByDeviceId(event.getDeviceId());

c.getButton(OuyaController.BUTTON_DPAD_UP)

But this is never returning true. I reviewed the documentation here: https://github.com/ouya/docs/blob/master/controllers.md but didn't see anything. I don't know what I am missing. Any suggestions?

Comments

  • jbanesjbanes Posts: 45Member
    As far as I understand, DPAD support is a bit broken in the ODK at the moment. I believe it's on their list of things to fix, but a bit more prodding wouldn't hurt. :)

    The good news is that the events appear to come through as generic motion events for a Joystick. So you can always add a listener to your Activity. 

    The bad news is that I still haven't decoded the correct axis information and I am unsure if whatever solution I do find is portable. (Though to date, everything with the controls seems to work the same between android devices and emulators.)
  • tacograveyardtacograveyard Posts: 18Member
    Thanks jbanes!

    It seems like

    c.getButton(OuyaController.BUTTON_DPAD_UP)

    doesn't work but

    keyCode == OuyaController.BUTTON_DPAD_UP

    works on the keyDown/keyUp events. Button presses aren't registering 100% of the time and sometimes holding the button down generates a bunch of event and other times it only generates a single event. This testing is all on an actual OUYA dev kit.
  • jbanesjbanes Posts: 45Member
    There's a couple of things going on here that are exasperating the current situation:
    1. Android doesn't appear to separate the concept of a button press away from a repeating "typed" character. Thus "keydown" events fire at the retype rate. (Rather annoying if you ask me.)

    2. The OuyaController class, which is supposed to handle all this for us, is rather buggy. It doesn't appear to handle all situations correctly, leading to the DPad issue for one. Part of this may be the underlying Android system which somehow manages both consistency and inconsistency in controller handling at the same time.
    My best advice in the short term is handle the keycodes for the DPad directly (surprised you're getting them; I don't even get that!) and map them to a set of booleans. Turn the booleans on when you receive a down event and off when you receive an up event. That should compensate for the auto repeat.

    If you actually need event-based handling (e.g. fire only once when pressed) have a "consumed" boolean that you set to true after you use the value. Your check for pressed would then become (pressed && !consumed). Set the consumed variable to false when the user lets go of the button. That should precisely simulate event-based handling of the buttons.
  • tacograveyardtacograveyard Posts: 18Member
    Yeah, that is the approach I ended up using. I would use the analog stick, but the game I am trying to put together for #ouyacreate really works best with the dpad. I suppose all this pain and suffering is what I get for trying to start this thing when there was only 2 days remaining. Thanks!
Sign In or Register to comment.