Ultimate profile for Switch/XInput/Gamecube Backends

[ZeroniaFX]

trafficstars

• Fixed reverse UpTilt rightwards. (It used to input Reverse Up Smash if hit fast enough)

• Fixed reverse DTilt for both directions. Works consistently now. (It just didn't work before)

• MX walking works with Toon Link's passive shield, matching the speed in Arte's firmware.

• MY walking is slower (closer to Arte's firmware). Attempting to attack during this will jab, similarly to Arte's firmware.

[JonnyHaystack]

Did you test this through GCC adapter or over USB? Just checking because the coordinates are currently not scaled correctly over USB to Switch, so any mode changes should be tested on adapter.

[ZeroniaFX]

I only tested this over USB. I can test it over GCC adapter when I get a GC to Type C cable.

[avahe-kellenberger]

@ZeroniaFX I can test this with a gcc adapter, but could you describe the inputs used here and the expected results? E.g. how I should reverse dtilt, etc.

[avahe-kellenberger]

One issue I've noticed so far, is that we cannot crouch on platforms with modX + down

[ZeroniaFX]

@avahe-kellenberger "MY + DownLeft/DownRight + A" should perform an instant turnaround Dtilt in the chosen direction, even during a dash.

Also, I don't believe I modified MX+Down in this pull request. Though if it's supposed to crouch, I can add it.

[avahe-kellenberger]

It may just be a difference I noticed between stock firmware and haybox - I can't seem to be able to crouch on platforms with mod X (and mod Y will just make you fall through platforms, which is fine I guess?)

[avahe-kellenberger]

Now that I think about it, I believe modx and mody should have the same behavior as far as tilting shields and dropping through platforms. outputs.leftStickY = ANALOG_STICK_NEUTRAL + (directions.y * 50); allows the user to crouch on platforms and tilt shields.

I also was testing Toon Link shield walking (with your changes using modX), and he seems to be walking too quickly. It works with modY, however. One of the written goals of the Ultimate mode of the stock firmware, was to have modX walking be the fastest speed before running. What do you think about maintaining this goal for HayBox? We can still walk/shield with modY.

---

I made the relevant changes on my branch at https://github.com/avahe-kellenberger/HayBox/commit/79e6834700d650fb13fb9e7639a3a07407346ee3 if you want to try out those values. Seems to be working well, so far. Will do more extensive testing throughout the week.

[ZeroniaFX]

I intend MX Horizontal to be the fastest walk for Toon Link/Young Link's passive shield. This was possible with the same input on CL-FW and Arte's firmware.

The fastest walk is still achievable trough several methods:

• Walking then letting go of MX, still holding left/right.
• Running then tapping MX.
• With tap jump off: Move the stick up and then forward (upside-down quarter circle).

[ZeroniaFX]

Also, my GCC to Type C cable arrived. I've been documenting some of the values... and wow, the values are way more different than I expected.

	GCC X-axis	GCC Y-axis	Pro Left	Pro Right	Pro Up	Pro Down	Description
MX + Horizontal	40		51	51			Most horizontal Tink shield walk and FTilt out-of-dash.
MX Angled Horizontal Attacks		44			57	58	Most vertical for FTilt/FAir/BAir.
MY + Horizontal	26		25	26			Minimum horizontal for walk.
Tested in Switch "Calibrate Control Sticks"
Max Range Analog Values	71	71	99.1	100.0	100.0	99.1	Minimum to reach highest analog value.
Neutral Analog Values	15	15	~0	~0	-1	+1	Max values to keep stick "neutral"
							Example: On GCC, 15 won't move at all, 16 will slightly.
							I guess Pro has no deadzone. It's off center too.
							Need to move stick down to achieve "neutral".

[ZeroniaFX]

Because of how different the values are, I am doubting GCC and SwitchBackend can share the same profile currently.

...

I'm wondering if the GCC inputs can be scaled to be more like the SwitchBackend.

• Currently, GCC works with values 16 to 71.
• SwitchBackend works with values 0 to 100 (or very close #41).

I believe values 0 to 100 would be easier to work with since they can be used as coordinates on a graph:

(Literally a screenshot of the B0XX manual with numbers I drew over it. I've tested it and it seems to work on SwitchBackend https://github.com/ZeroniaFX/HayBox/commit/93d679bfd1442d9ecd1ea2cdadba823431efe5fc.)

[avahe-kellenberger]

I like it And just to clarify, the numbers you had for modX walking previously were too fast for tink shield walk - I'd be happy to do more testing as you make changes to the PR

[JonnyHaystack]

@ZeroniaFX have you tried removing the hacky 1.25x scaling I put in this commit? https://github.com/JonnyHaystack/HayBox/commit/0bd3f7be23577482104dd87b2541cba06d650956

Probably better to test without that when doing the comparison, so that you're just looking at how exactly the Switch handles the raw values rather than in combination with my weird scaling that I was attempting to compensate for the Switch's scaling with.

[ZeroniaFX]

After removing the 1.25x scaling, I got these results:

[ZeroniaFX]

Updated the PR with most of my current progress. Everything seems to be working fine on the SwitchBackend. Still working on scaling the GCC inputs.

(also, why does just renaming my branch close the PR...)

[ZeroniaFX]

Updated Ultimate profile to work on Switch/XInput/GamecubeBackends.

GCC scaling is not 100% equal to SwitchPro. On a Switch console, it seems GCC values below 50 are scaled down, and values above 50 are scaled up. Despite this, I managed to find values that work for both backends.

I retested all the values. The only issue I found is MY+Down does not crouch on platform with GCC. On Switch, the range is 65-67. On GCC, the range is 62-63.

[ZeroniaFX]

For those curious about the GCC scaling:

[avahe-kellenberger]

If the scaling issues are fixed it will probably make PR #26 viable - been trying out native switch support with my R4 and there are definitely weird issues caused by improper scaling

[JonnyHaystack]

I'm not sure what the current state of this PR is right now, but I'm seeing changes to GamecubeBackend, which should not be the case. That will break all other modes on GamecubeBackend.

[ZeroniaFX]

Added UpB angles with the option of medium and minimum magnitude.

[ZeroniaFX]

@JonnyHaystack

I'm not sure what the current state of this PR is right now, but I'm seeing changes to GamecubeBackend, which should not be the case. That will break all other modes on GamecubeBackend.

Yeah, I'm not sure how to rescale the GamecubeBackend without messing with the other modes. Changing the analog stick values on the Ultimate.cpp would mess with the coords I intended for SwitchBackend.

I could make another Ultimate profile specifically for the GamecubeBackend if the scaling can't be fixed.

Also, I managed to run gamepad-tester.com on a modded Switch using switch-remote-play. This can report the analog inputs of the Gamecube adapter. If this option isn't available to you, I can offer more data points using this.

[JonnyHaystack]

Yeah, I'm not sure how to rescale the GamecubeBackend without messing with the other modes. Changing the analog stick values on the Ultimate.cpp would mess with the coords I intended for SwitchBackend. I could make another Ultimate profile specifically for the GamecubeBackend if the scaling can't be fixed.

To be clear, I am not merging anything that messes with the scaling of XInputBackend or GamecubeBackend. The only one that needs scaling changes is NintendoSwitchBackend. Ultimate mode should be using values that work on GamecubeBackend primarily, and we can make sure the scaling is right on NintendoSwitchBackend so that Ultimate mode works the same on both backends.

Also, I managed to run gamepad-tester.com on a modded Switch using switch-remote-play. This can report the analog inputs of the Gamecube adapter. If this option isn't available to you, I can offer more data points using this.

Yeah that would be great, thanks.

[ZeroniaFX]

Here's some more data points

[JonnyHaystack]

Thanks for those data points - they were extremely helpful. I have managed to fit deadzone and scaling functions to get something almost identical to the scaling the Switch applies to GameCube controller inputs. I have pushed these changes to the branch fix/switch_backend_scaling for now. If you could test that to see if anything's still off it would be really appreciated. Might still need to add that offset of 1 if that's an issue. If you could do any testing of diagonals as well that would be very informative, because I'm not sure if the deadzone the Switch applies is square or circular.

[ZeroniaFX]

Here's data points based on the new scaling.

Also, I tried testing with 256 instead of 255 in _report.ly = 255 - apply_radius. This seems to fix stick being off-centered when it should be neutral.

[JonnyHaystack]

@ZeroniaFX Do the outputs match with GamecubeBackend if you use 256 instead of 255? Or are they at least closer overall? Only other thing I can think to try is going back to deadzone 11, which you can try by changing the number 15 to 11 here.