Closed JonnyHaystack closed 3 years ago
My analog triggers have a physical range of roughly 30 to 240. 31 seems like a decent resting position. The Gamecube isn't the one who sends the initial values, it sends a command to the controller and it reads the return data. This is used to calibrate the origin. See gc_origin
in Gamecube.c
That said, I don't believe the controller calibrates the analog triggers, only the sticks, but I might be wrong.
Every time you write to the console it initializes the data with default values, but then immediately rewrites it with the report you send it. This shouldn't really be an issue either, assuming the data you're sending it is valid. See CGamecubeConsole::write
inGamecubeAPI.hpp
This library stores data in a different order/format than NintendoSpy uses. The newest version of NintendoSpy has support for this library, but you have to download the source and compile it yourself with visual studio. (community version has a free trial.) I had a lot of teething issues trying to make it work at first, but I currently have no issues with this library with NintendoSpy now that the newest version supports it.
My analog triggers have a physical range of roughly 30 to 240. 31 seems like a decent resting position. The Gamecube isn't the one who sends the initial values, it sends a command to the controller and it reads the return data. This is used to calibrate the origin. See
gc_origin
inGamecube.c
That said, I don't believe the controller calibrates the analog triggers, only the sticks, but I might be wrong.
Sorry, I did actually mean to say GameCube controller. Triggers are definitely calibrated too. It's a fairly common thing in the SSBM community to "trigger trick", meaning you hold down a trigger when plugging your controller in so that the trigger doesn't yield an analog input but still gives a digital input when fully pressed. I'm not sure there's any particular reason why this library should initialise the triggers to a specific value based on the official GCC's physical range.
This library stores data in a different order/format than NintendoSpy uses. The newest version of NintendoSpy has support for this library, but you have to download the source and compile it yourself with visual studio. (community version has a free trial.) I had a lot of teething issues trying to make it work at first, but I currently have no issues with this library with NintendoSpy now that the newest version supports it.
So you just need a newer version of the NintendoSpy desktop program? No firmware update needed on the input viewer device? If so I will get someone to test that, thank you.
What @Skuzee says is true. I've just used the physical defaults, as this library can also act as controller itself and I try to send realistic data. You are free to overwrite it, it should not cause a problem.
Hi, was just wondering why analog L and R are set to 31 (0x1F) in defaultGamecubeData https://github.com/NicoHood/Nintendo/blob/master/src/GamecubeAPI.h#L30
Does an official GameCube actually send that as the initial value? If so, do you have any idea why? I'm a bit confused about how stick/trigger calibration works, and have seen people having some issues with hardware-based NintendoSpy input viewers showing incorrect analog stick positions when used with a controller that runs on this library.