diff --git a/book.toml b/book.toml index 97a47e6..d2d43af 100644 --- a/book.toml +++ b/book.toml @@ -7,3 +7,6 @@ title = "NaxGCC Documentation" [preprocessor.katex] after = ["links"] + +[preprocessor.toc] +marker = "[[_TOC_]]" diff --git a/flake.nix b/flake.nix index fd94f95..e5c9556 100644 --- a/flake.nix +++ b/flake.nix @@ -36,7 +36,7 @@ devShells.default = pkgs.mkShell { nativeBuildInputs = builtins.attrValues { - inherit (pkgs) mdbook mdbook-katex; + inherit (pkgs) mdbook mdbook-katex mdbook-toc; }; }; }); diff --git a/src/configuration.md b/src/configuration.md index 951a35a..ece9f3e 100644 --- a/src/configuration.md +++ b/src/configuration.md @@ -2,16 +2,7 @@ This page contains all the information needed for configuring & calibrating your controller. Click on any of the links below to quickly navigate to a given section. -1. [Initial Calibration](#initial-calibration) -2. [Configuration Options](#configuration-options) - - [Stick Calibration](#stick-calibration) - - [Smart Snapback Adjustment](#smart-snapback-adjustment) - - [Waveshaping Adjustment](#waveshaping-adjustment) - - [Stick Scaling Adjustment](#stick-scaling-adjustment) - - [Cardinal Snapping Adjustment](#cardinal-snapping-adjustment) - - [Axis Smoothing Adjustment](#axis-smoothing-adjustment) - - [Input Consistency Mode Toggle](#input-consistency-mode-toggle) - - [Display Values](#display-values) +[[_TOC_]] # Initial Calibration diff --git a/src/input-consistency.md b/src/input-consistency.md index c044d15..32f56ba 100644 --- a/src/input-consistency.md +++ b/src/input-consistency.md @@ -4,6 +4,8 @@ This is a rather technical document about USB polling, input latency, and the is > **NOTE:** "Input consistency" and "input integrity" are used interchangeably in this document. +[[_TOC_]] + ## General Info The vast majority of human interface devices (HIDs) transmit their states over USB using a technique known as "polling". Essentially, these devices (clients) advertise themselves as supporting a certain polling interval/frequency to whatever device they're attached to (hosts). The host then polls the client at the desired frequency, or at a lower one (= not as often, = more slowly) if the host doesn't support the client's desired frequency. @@ -38,7 +40,7 @@ Again in plain English, if you have multiple polling rates, the frame window in This is how it is when you're playing with a PhobGCC (the best GCC currently available) on a _first party_ GCC adapter from Nintendo. Note that third party adapters may very well be much worse than this, because they could poll the GCC at an even lower frequency (= more slowly). -**BONUS QUESTION:** What if the sum of all polling intervals is larger than the frame time window, i.e. $\sum_{i=1}^nT_i > T_f$ ? That's right, in this case your inputs are _always_ RNG! (good thing that's not the case here though) +> **BONUS QUESTION:** What if the sum of all polling intervals is larger than the frame time window, i.e. $\sum_{i=1}^nT_i > T_f$ ? That's right, in this case your inputs are _always_ RNG! (good thing that's not the case here though) ## The Solution @@ -75,7 +77,7 @@ In consistency mode, the NaxGCC introduces a variable delay in order to wait res ### "Super Hack" Mode -In "super hack" mode, the NaxGCC avoids responding to the console's poll requests until the controller state has changed, _and_ at least $8.\overline{3}\mathrm{ms}$ have elapsed since the last poll request. This ensures that, for inputs made more than $8.\overline{3}\mathrm{ms}$ apart, the latency is minimized, since the state is immediately dispatched to, and interpreted by, the console, at a slight cost to input integrity for inputs made less than $8.\overline{3}\mathrm{ms}$ apart. +In "super hack" mode, the NaxGCC abstains from responding to the console's poll requests until the controller state has changed, _and_ at least $8.\overline{3}\mathrm{ms}$ have elapsed since the last poll request. This ensures that, for inputs made more than $8.\overline{3}\mathrm{ms}$ apart, the latency is minimized, since the state is immediately dispatched to, and interpreted by, the console, at a slight cost to input integrity for inputs made less than $8.\overline{3}\mathrm{ms}$ apart. > **WARNING:** This mode is currently experimental, as it is still undergoing extensive testing, and is currently **not** recommended for tournament play. diff --git a/src/introduction.md b/src/introduction.md index edd23c6..fb086ab 100644 --- a/src/introduction.md +++ b/src/introduction.md @@ -22,7 +22,7 @@ Because the NaxGCC connects directly to the console via USB, it already outperfo Further, the NaxGCC has a special "input consistency" mode (enabled by default), which ensures a $\gt 98\%$ input accuracy, compared to $\lt 75\%$ for any other controller (worse if there is an adapter in the mix, with the exception of the Lossless Adapter). -For details on how it works, have a look at our wiki. +For details on how it works, have a look at the [Input Consistency Modes](./input-consistency.md#input-consistency-modes). diff --git a/src/jlcpcb-parts-ordering.md b/src/jlcpcb-parts-ordering.md index 0aca356..34b3b4c 100644 --- a/src/jlcpcb-parts-ordering.md +++ b/src/jlcpcb-parts-ordering.md @@ -2,6 +2,8 @@ This is an illustrated guide to ordering NaxGCC PCBs via the JLCPCB Board House. +[[_TOC_]] + ## JLC Ordering Process Overview This is very important, or else you will get nonfunctional boards.