The patch set text_speed scales the typewriter speed of a message the game lets the player skip (fast, three times as
fast, its scripted waits as long) or runs the game's own skip on the first frame of each page (instant). Messages the
game marks unskippable, such as those that turn their page on a timer, keep the game's speed. The setting is live and
has a row on the Game tab in all four menu languages; with it at normal the set is off.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The driver's sleep sits where the game's frame starts: at its first pad read or window image acquire after a present,
whichever comes first, before the input is sampled. The frame's number, the count of the game's presents, goes with
its work: the guest thread marks the simulation and the first submission, the replaying thread tags its queue
submissions and marks their end, and the present thread marks the host present, which carries the number too. The
window's swapchain is made with the latency mode while NVIDIA's path is on, and remade when the setting changes.
While the mode is in effect the pacer holds nothing, so a picture goes out as soon as it is drawn and the limit is
kept by the driver before the pad is read; RivaTuner Statistics Server is kept out as with frame generation. The pacer
takes the limit back while a movie plays, while no host present goes out, and for the rest of the run when the frames
show the driver does not hold it. With the mode off every hook returns at its first check.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
The default strength is 130 to make up for what two motors lose. A linear actuator that takes the game's value needs none of that, and 1.3 times the amplitude clipped the strongest pulses at the safe maximum. The HD path now divides by the default, so the setting scales from the game's own amplitude.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
With NX2NAVI_RUMBLE_HD=1 (live, off by default) the gamepad the game reads, when it is a Switch Pro Controller, a
single Joy-Con or a pair of them, gets each side's low and high band with its own frequency and amplitude in the
controller's rumble report, and no dual-motor call any more. A Pro Controller and a single Joy-Con take the report
through SDL's effect call, over USB and Bluetooth; SDL refuses that call for a combined pair, so a pair's reports are
written to its two HID devices directly. Every other gamepad, the Switch 2 controllers included, keeps the motors.
The game's thread posts its newest values and a thread of input.c writes the reports: at most one every 15 ms
(rumble_hd_ms), a held value again every 30 ms, and the neutral value when the game stops sending for 250 ms, when
another gamepad takes over, when the setting is turned off and before the process ends. The rumble strength scales the
amplitude and rumble = 0 silences this path as well. With the setting off nothing is written to the controller: the
log line at the take names it by its ids, and the first report is the trial.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
With it on, the game draws from a camera of the menu's instead of its own, in play and in cutscenes. The left stick moves it along its view and sideways, the right stick turns it, ZR and ZL raise and lower it, R makes it faster and L slower, and Link stands meanwhile; or the camera stays where it is and the pad plays the game.
It works inside the game's own camera update: a new patch site sends the instruction at which the frame's position, target and up vector are final to a host function, which replaces them for the camera that follows Link and the one the events direct, so the game draws, culls and loads detail for what the free camera sees. The camera of the interface's 3D models and the one the sound follows stay the game's. The set is off unless the menu switches it on. A teleport's arrival starts the free camera again from the game's view.
Tested in Hyrule Field with scripted stick input (turn, rise, strafe, with Link's position unchanged), with the pad playing while the camera stays, across a teleport to Kakariko Village, during the Kakariko arrival cutscene, and switched on by a click in the menu.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
With debug_menu = 1 (off by default; the Game tab has the switch) F9 opens a panel on the left edge in the
performance overlay's look, with the game in view beside it. ui/menu.cpp lays it out in the settings menu's place,
so its input and the game's blocked pad are the menu's own. Typed characters now reach the menu for its text fields.
Flags: the game's 11,292 on/off flags are read from its game data manager, and a click changes one through the
game's own function on the game's thread at its pad read (runtime/debug_tools.c dbg_tick), so the game applies it
at its next update as it does its own changes. The game knows a flag by the hash of its name only; the names shown
are found in the player's own event flow files, hashed and matched when the panel first opens (2,250 of them from
915 files in 0.2 s), and none is kept in the code. World: Link's position, and a speed factor from 0.05 to 8 that
multiplies the step the runtime gives the game each frame (measured 0.50 at 0.5x). Memory: a search of the heap
for a value of 1, 2 or 4 bytes or a float (about 2 s), narrowed by equals, changed, unchanged, went up or went
down, with a value to set at a place or to hold there every frame.
Tested through the window's own messages: F9 opened it, a click on a flag set that flag in the game, text typed
into the filter narrowed the list, and F9 closed it; a scripted run set and held a value and put it back.
Teleporting, a free camera and starting cutscenes are not in it: writing Link's position, or every copy of it in
the heap, moved him back within three frames, so they need the game's own warp, scene-change and event functions.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Each file that contains copied code names its copyright holder and license and points at THIRD_PARTY_NOTICES.md; zlib code keeps its full notice and the mark that it was altered. Comments and probe text only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Comments say what the code does and why, docs/maxwell.md keeps the Maxwell facts, and fetch_refs.sh clones only the checkout the build reads. Code is unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The NVN2 front end and the SM86 to Maxwell shader lowering (tools/xlate/AmpereLowering.cs, mesh and task stages,
bindless texture pools, BRX jump tables, the NVN2 compute c0 layout) with four translator patches (0017-0020) bring the
opening of the game to 58-60 fps on the Vulkan renderer.
This round fixes the haze: SM86 IPA is lowered as a plain Maxwell IPA.PASS (texture coordinates were corrected for
perspective twice); LDSM, TXD, both F2IP byte forms, HMMA, MOVM and HFMA2.RELU are lowered and spill mode has eight
uniform register groups; conditional rendering keeps the newest counter report per address and treats a report as
pending until its value is in guest memory, so occlusion tests and the depth clears around the depth copy behave; and
the upscaler stand-in decodes the post pass's sRGB picture before writing the linear target. Tensor-core programs keep
the stand-in unless NX2NAVI_NATIVE_TENSOR=1, because their lowering does not match the hardware yet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
