diff --git a/src/input-consistency.md b/src/input-consistency.md index 278ef4f..05bb87d 100644 --- a/src/input-consistency.md +++ b/src/input-consistency.md @@ -2,7 +2,7 @@ This is a rather technical document about USB polling, input latency, and the issues that arise with input consistency. If you only care about the NaxGCC's solutions to this problem, and not the background knowledge, you can skip ahead to the [Input Consistency Modes](#input-consistency-modes) section. -> **NOTE:** "Input consistency" and "input integrity" are used interchangeably in this document. +> **NOTE:** "Input consistency" and "input integrity" are used interchangeably in this document, and refer to the predictability with regards to the frame on which your input will come out. [[_TOC_]] @@ -12,7 +12,7 @@ The vast majority of human interface devices (HIDs) transmit their states over U The Nintendo Switch supports polling USB devices at up to $125\mathrm{Hz}$, or once every $8\mathrm{ms}$. A game running at $60\mathrm{fps}$ takes $\approx16.66\mathrm{ms}$ to draw a frame, meaning with a polling rate of $8\mathrm{ms}$, a USB device would be able to update its state _up to_ 3 times per frame. Notice how I said "up to", because this is where things start to get wonky. -The reason it's "up to 3 times" and not "3 times, period" is because the USB polling and the game's frame draws are not in sync. Otherwise, a polling interval of $\approx16.66\mathrm{ms}$ would be perfectly sufficient, provided the host polls the adapter right before the frame is supposed to be drawn$^1$. Due to technical reasons, this is not possible however, so we are stuck with two asynchronous intervals: Polling & frame draws. +The reason it's "up to 3 times" and not "3 times, period" is because the USB polling and the game's frame draws are not multiples/divisors of each other, which causes them to continuously shift their offset to one another. Even a polling interval of $\approx16.66\mathrm{ms}$ would be perfectly sufficient, provided the host polls the adapter right before the frame is supposed to be drawn$^1$. Due to technical reasons, this is not possible however, so we are stuck with two asynchronous intervals: Polling & frame draws. $^1$even if the host didn't poll the adapter right before the frame is drawn, it would still be fine, because as long as the polling interval is a divisor of the frame draw time, at least input _integrity_ would be guaranteed, even if _latency_ could still be variable depending on when your device was plugged in @@ -73,7 +73,7 @@ In regular mode, the NaxGCC will not attempt to modify the polling rate of the c In consistency mode, the NaxGCC introduces a variable delay in order to wait responding to a poll request from the console until exactly $8.\overline{3}\mathrm{ms}$ (half a frame) have elapsed since the last status update. This ensures that the controller is polled exactly twice as often as the game updates and (nearly) eliminates the chance of your inputs being misinterpreted. This is the recommended mode for competitive play, and is the default mode for the NaxGCC. -> **NOTE:** While this is not exactly in-spec behavior for a USB device, it is still within the realm of what is possible with USB, and has been extensively tested to ensure that it does not cause any issues with the console. +> **NOTE:** While this is not exactly in-spec behavior for a USB device, it is still within the realm of what is generally considered to be "acceptable" with USB, and has been extensively tested to ensure that it does not cause any issues with the console. ### "Super Hack" Mode @@ -81,4 +81,4 @@ In "super hack" mode, the NaxGCC abstains from responding to the console's poll > **WARNING:** This mode is currently experimental, as it is still undergoing extensive testing, and is currently **not** recommended for tournament play. -> **NOTE:** "Super Hack" does not refer to this being a hack that is super, but rather something that is super hacky, since this pretty much out of spec behavior for a USB device. +> **NOTE:** "Super Hack" does not refer to this being a hack that is super, but rather something that is super hacky, since this pretty much out of spec behavior for a USB HID.