›

OuyaController getAxisValue resolution

tsmastertsmaster Posts: 7Member
in OUYA Hardware
I got my first tiny app up and running, it grabs the left stick position from each of the controllers and positions a ball onscreen based on where the stick is being held.

I'm surprised at the "chunkiness" of the values I'm getting back from getAxisValue() - rather than smooth analog values between -1.0 and 1.0, I'm getting ~32 discrete values in that range. Moreover, when I try to sweep out the extents that the stick can reach, I notice a big "notch" when I get to a multiple of 45 degrees - that is, if I hold the stick to the right, the X,Y values I get are (1.0, 0.0), as I expect, and as I move it counter-clockwise, I get values that are close to a radius 1.0 circle, until I get to right and up, when the X,Y values are (0.5, -0.5), which is noticeably short of the unit circle. This effect is observable on each of the four quadrants.

Is this a known behavior of the hardware? Or is there a "stick resolution" mode that I need to set up to increase the smoothness of the values I get back?

I can imagine some games could specify a dead zone and then normalize the values to the unit circle, but then we're dealing with just another D-pad.

Comments

  • tsmastertsmaster Posts: 7Member
    APK here: https://sites.google.com/site/bigdicegamestutorials/newtutorials/tutorial-ou01---using-ouya-controllers-inside-a-playn-game/controllersample-android-1.0-SNAPSHOT.apk?attredirects=0&d=1
  • HicsyHicsy Posts: 177Member
    wow ill build a quick app now and have a look! Maybe something to send in an email as a fault
    Can't find aapt.exe? Temp fix: Copy another one from 'android_sdk/build-tools/17.0.0' back to your 'platform-tools'
           -=Hicsy=-
    PM me        Facebook

  • GodlyPerfectionGodlyPerfection Posts: 140Member
    I'd like to echo that I just installed this and tried it out... I'm getting the exact same problems as he is. The values returned are not smooth between each other at all and there is a noticeable shortness to the length of 45 degree angles in each quadrant.
    Aggro Tactics - A tactical strategy virtual board game built with Unity3D 4.0, designed around the concept of Threat/Aggro inspired by the mechanics of chess and a customizable party like in table top games.

    Founder of ReachingPerfection.com
  • HicsyHicsy Posts: 177Member
    BTW, the app you made has both APP and GAME intent.catergories - although this isnt checked yet, OUYA might block this later. Utilities should come under the "app" category in your manifest.
     I havent spent much time with your code, but the 'notchy' feeling seems to be coming from the fact that ur code is dividing the polling data into 32 parts.
    like here: com.bigdicegames.core : ControllerSample : update()
     I think that combined with the ODK standard dead-zone-shift (compensation?) is causing the jumps - it's also apparent in the ouya-controller-testapp sdf
     Ill pickup a case of beer tomorrow and try to nut it out but it seems to be just bad math in the ODK.

     also i'm too tired to do the math right now, but it cuts between 87%-100% (rounded off) and 0%-13% each quarter rotation so i think thats like... 74% movement. In theory without an (incorrectly coded) deadzone you should therefor still have smooth movement if you only push the stick 74% in any direction; obviously therefore the correct deadzone-shift would then extend those results (and anything above that) to 100%, then add deadzone numbers to the BASE (not the top) of the movement calculation...
    Can't find aapt.exe? Temp fix: Copy another one from 'android_sdk/build-tools/17.0.0' back to your 'platform-tools'
           -=Hicsy=-
    PM me        Facebook

  • tsmastertsmaster Posts: 7Member
    Hicsy said:
    BTW, the app you made has both APP and GAME intent.catergories - although this isnt checked yet, OUYA might block this later. Utilities should come under the "app" category in your manifest. 
    Sure, if I was making a game, I'd just have the one intent. I was just experimenting to make sure that it worked. That's not really important now.
    I havent spent much time with your code, but the 'notchy' feeling seems to be coming from the fact that ur code is dividing the polling data into 32 parts.
    I don't think that's it at all. Here's the code that I'm using: 

     x = 400+200*c.getAxisValue(OuyaController.AXIS_LS_X); 
     y = 200+200*c.getAxisValue(OuyaController.AXIS_LS_Y);

    So, there's no quantization that I'm doing after I get the values from the controller.

    The "notchy" phenomenon I was describing isn't a quantization problem, it's a problem that the maximum I can extend a stick in the 45 degree direction is (0.5, 0.5), instead of (0.707, 0.707). If there was a dead zone problem, I would expect it to be the same in all directions.

    For a lot of games, I can work around this - first, check for a deadzone, and clamp to (0, 0) if it's there. Otherwise, clamp to full magnitude, which would work around the notch problem I've described. If I wanted to make a flight sim with smooth response to stick position, this wouldn't be appropriate.
Sign In or Register to comment.