Stick behaviour differs from the original

[wasbaun]

og360 firmware 2.1, bought the hardware from chimemric orage 8bitdo Adapter, newest firmware.

Hi there,

I'm not sure if this is the right way to ask the question but i've noticed that the behaviour of the left stick of an xbox one s controller connected via orange 8bitdo adapter seems to be different from the behaviour of a stick of an original s controller.

I noticed it when playing james bond agent under fire. diagonal movement is faster with the original controller directly connected to the xbox than via the og360 adapter with 8bitdo adapter and an xbox one s bluetooth controller. Tested it also with timesplitters 3, same thing.

Then I found a controller test tool named "testlaunch" https://www.reddit.com/r/originalxbox/wiki/testlaunch . In the program on the xbox, you can test various things. In the mode for adjusting the deadzone, I saw, that the range of the original controller was more like a rectangular shape with rounded edges. the one s controller via og360 had a round shape.

I testet it on the og360 with a wired xbox one controller, a switch pro controller and with a wired xbox360 controller, same result. Unfortunatly I dont have a wireless xbox 360 receiver to test.

In this controller test tool is also a mode, where you have to press/use all buttons/sticks to pass a test. With og360 it gets stuck at the left stick, where you have to move the stick in every direction especialy diagonals.

Could you please give me a hint?

[Ryzee119]

ogx360 directly passes through the analog stick values, so what it's outputting is directly what it is getting from the 8bitdo adaptor (which must be circular) The mechanical movement of the stick is ofcourse circular so I expect the more modern controllers are actually 'better'.

If this is an actual issue, the fix is to mathematically scale the stick range to a rectangle with rounded edges here:

https://github.com/Ryzee119/ogx360/blob/db870c72b14f1b8fce183a23547dc907f335ec1d/Firmware/src/master.cpp#L204-L207

Which is probably to just multiply the scale by say 1.25, then cap the limits to int16_t values. Maybe something like this:

//FIXME: More efficient to do a bitshift and addition instead of a float mutliplication? i.e:
//scaledLX =  (int32_t)usbh_xstate->sThumbLX +  (int32_t)usbh_xstate->sThumbLX >> 4; (1 + 1/4 = 1.25)

int32_t scaledLX = (int32_t)usbh_xstate->sThumbLX * 1.25; //FIXME?
scaledLX = (scaledLX > INT16_MAX) ? scaledLX = INT16_MAX :
           (scaledLX < INT16_MIN) ? scaledLX = INT16_MIN  : scaledLX;
_usbd_duke->in.leftStickX  = (int16_t)scaledLX;

Repeat for LY, RX, RY

Does the Duke and S controller have the same output profile?

[Ryzee119]

Closing as stale. Basically different controllers have different analog stick profiles. ogx360 will correct them all to signed 16bit values that the og xbox expects however the linearity or sensistivty is controller specific.

I guess a deadzone/sensitivity/linearity adjustment system that can happen during runtime couldnt hurt but is behond the scope of this issue.