The bindings dropped every mouse button while the cursor was not captured, and the menu pointer releases the capture,
so side buttons bound to L and R turned the menu's tabs only in the frames before the pointer appeared. While the menu
pointer is shown and over the window, the middle and side buttons now count; the left and right buttons stay the
menu's A and B.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On the map the mouse moves the cursor, so it had no way to zoom: the zoom is the right stick's y, which only the
keys and a pad reached. While the map is open, each wheel notch is now a full-tilt push of that stick for 100 ms with
50 ms of neutral after it (a turn away from the player zooms in). A fast scroll's notches wait their turn, at most four,
and a turn the other way drops them. The wheel stays unbound elsewhere.
The back ends count the notches while the cursor is captured (input_win.c from raw input's usButtonData, input_sdl.c
from SDL_EVENT_MOUSE_WHEEL), keeping a high-resolution wheel's part of a notch (ikb_wheel_take).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Only the free camera took the mouse as degrees. The other camera modes took it as stick input, which their own speeds,
frame time, slow motion and curves reshaped, with the on-foot camera's square-root pitch shaping on top: bow aiming was
far too sensitive vertically on slow movements, abilities and the Purah Pad camera eased their pitch, lock-on turned
27% slower, and climbing, shield surfing and the rest each turned at their own rate.
Each camera mode's update now loads the gamepad's part of the stick where it computes its turn and adds the mouse's
degrees where it adds that turn to its angle (runtime/mouse_direct.c camera_load, the load sites of
recomp/patches-v143.txt): aiming, scope, abilities (and Recall's cursor), horse, Purah Pad camera, lock-on, bow
lock-on, wall and object climbing, the waterfall's turn, shield surfing, wakeboard and the dialogue cameras. Recall's
cursor moves so that its aim turns as many degrees a count. The waterfall's height and the horse's empty lock-on are
not angles and stay stick input, now linear. A step whose mouse motion no hook took is logged with the camera's name.
Holding L to soothe the horse gave the mouse to the ability wheel's virtual cursor, a held stick for the camera: the
mouse goes to the wheel and the D-pad strips only while their screen has the focus (menu_cursor.c
menu_cursor_shortcut). A mouse shake no longer plays a 0.8 s swing after it: the right stick follows the mouse's own
swings and lets go when it rests, and the camera does not turn by that swing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The game detaches a fused part when the right stick swings left and right a few times. In direct mode the mouse never
reaches that stick, so shaking the mouse did nothing and only the shake key worked. A shake of the mouse while
Ultrahand holds an object (at least three changes of direction within 0.6 s, each swing worth 10 degrees of camera turn
or more) now plays the shake key's right-stick swing. Turning a held object back and forth at an ordinary pace takes
longer and does not count.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The free-orbit camera turned 0.08 degrees per count while the other cameras (the bow, the abilities) took the mouse as
0.01 stick units a count, about 0.023 degrees for yaw and through the camera's signed-square pitch for y, so the bow
turned at half the speed and small vertical moves barely moved it. Every camera now turns 70/1500 = 0.0467 degrees
per count: the stick path gets 0.02 a count for x and the signed square root for y, so pitch is linear and as fast as
yaw. While the player uses an ability (the action verb UseSpecialPower, read from the player actor with the 1.4.3
placement), the ability camera's own linear scales are undone instead. stick_sens is divided out, Ultrahand's held
object gets the camera's stick value a count (at most three full tilts a step), and mouse_aim_scale (0.1 to 3)
scales the mouse while the bow is drawn.
The game's lock-on, recenter and aiming override released the mouse's pitch hold and restored the target from before
it, so after a shot the camera sprang back to that pitch, or to the game's default target. The mouse now lets go
without restoring, and when the override ends (or the camera went 100 ms without a step) it holds the pitch the
camera has then. A gamepad's vertical input still hands the pitch back to the game.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A tab switch or a popup opening drops the game's focus box for a frame or two. The menu pointer read that as the menu
closing: the mouse camera captured the cursor again and, when the next tab took the focus, the pointer came back in the
middle of the window. A focus gap of up to 300 ms now keeps the pointer where it is.
The map has no focus box, so it stayed gameplay and the mouse drove the right stick, which zooms the map. The open
screens in eui::ScreenMgr's list now find the map (the Purah Pad's frame with AppMap_00 and the menu background; the
Scope opens AppMap_00 without the background), and there the mouse is the left stick, which moves the map's cursor.
The list is read every 100 ms, as each screen costs memory queries.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
G (bind_SHAKE, keys only) swings the right stick left and right for 0.8 s, longer while held, so a part comes off
without shaking the arrow keys by hand. The pad keeps shaking its own stick. Remappable in the Controls tab.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The camera input's activity hook wrote the flags to +0x418, but the game's next instruction stores w8 over them
(1.4.3 main+0x874d80), so a mouse-only turn still read as idle. The hook now changes w8.
The free-orbit hooks rewrote the camera stick input from the last sample even in steps without mouse motion; they now
take a step only when the mouse moved in it or holds the pitch, so a gamepad-only step reaches the camera as the game
made it.
The mouse shake gesture for detaching parts is gone: three 24-count reversals fire while a held object is turned back
and forth. Arrow keys or the pad's right stick shake as before.
The menu pointer comes only while the keyboard and mouse are the device used last (input_kbm_last): a gamepad player
sees the menus as on the console. Raw mouse travel is counted while the cursor is released too, so moving the mouse
brings the pointer back.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
While one of the game's menus has its focus box (the title, the save list, the inventory, Options, shops,
dialogue choices), the cursor is released from the mouse camera and shown; the item under the pointer takes
the focus as the d-pad would, a left click is A on it and a right click is B. runtime/menu_cursor.c reads
eui's screens at each pad read and moves the focus with the writes eui::BoxCursorMgr::moveBoxCursor makes,
adapted from Weeping of the Empire's totk_menu_cursor.cpp (1.0.0, MIT), with eui::ScreenMgr's instance placed
in 1.4.3 at main+0x3acf960. menu_cursor = 0 turns it off.
After the in-game menu or the text entry closes, input_poll kept the game's input blocked until one poll saw no
button and all four stick axes at 0. An input that never reads as released (a button another program holds down, a
key whose release went to another window, a stick resting outside its dead zone) kept the game deaf until restart
(#462, #494). Closing with Minus+Plus hid this: that poll zeroes the pad before the gate looks. Closing with Esc did
not. The wait now ends after 1 s with input held, and the log names what was held.
Repro: field save, a script holding the right stick at 3000, Esc opens and closes the menu, left-stick pulses after.
Before: 0.00 m/s for the 30 s after the close. After: Link walks from the second poll window on; the log line reads
"input: the menu closed 1 s ago and input is still held (buttons 0, sticks 0 0 3000 0)".
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The stick reading moved from input_win.c to input.c in dev, so the per-stick dead zone and
input_pad_stick_percent are applied there, under the platform mutex. The rows sit beside the
stick camera speed and walk key rows; pt-BR and zh-Hans get the per-stick texts.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The menu and the software keyboard hold the game's input until everything they saw is released again, and that release
test counted buttons only. With the walk key a keyboard stick moves part way without setting a direction bit, so the
movement went through the moment the menu or the text entry closed; the four axes count as held now.
The walk key's conflict note reads the bindings from a snapshot rather than the live table that the polling thread
rebuilds, and it looks at every key of an action instead of the two its cells show, so a key bound third still names the
action it presses.
Co-authored-by: deepseek-v4.1-flash-1017 <noreply@deepseek.com>
A keyboard key is all or nothing, so the game only ever saw a full tilt from it and the keyboard could not walk. While
the key named by walk_key is held, the two keyboard stick samples are scaled to walk_scale, the same thing yuzu and eden
do with their modifier setting; the gamepad's axes and the mouse camera keep their own values.
0.51 rather than half: a sample of 32767 times 0.5 is 16383, one short of the 16384 the game's stick-direction bits
need, so half a tilt would leave the direction clear while the axis moved. No key is on by default, because Shift is B
in the default bindings. The Controls tab lists the keys players pick, steps the scale in hundredths and names the
action a key also presses.
Co-authored-by: deepseek-v4.1-flash-1017 <noreply@deepseek.com>
The branch forked 79 commits before main and 98 before dev. Resolutions:
1. Aspect ratio: dev's implementation stays (camera patch at page +56 on 1.4.3, tools/ultrawide_layout.py layouts per
size in romfs-patches-<w>x<h>, the aspect = fit|stretch setting). The PR's second implementation is dropped: the
aspect sets of patches-v121.txt and patches-v143.txt (the 1.4.3 one patched the same viewport sites as dev's),
tools/aspect_layouts.py, the resolution.c shapes that limited game resolutions to 16:9, 16:10 and 21:9, and the
picture_fit setting. Its letterbox code (gfx_fit_rect) is kept and reads TOTK_ASPECT.
2. Code dev changed where the PR moved it: the stick dead zone, the test gamepad and the paddles go to input.c; the
DPI awareness, keep-awake and IME detach of gfx_window.c go to gfx_window_win.c; device fault reports and GPU
breadcrumbs to gfx_present.c. gfx_window_dpi gets an SDL version.
3. dev's Win32 calls in shared code go through platform.h: the shader cache pack reader (PlatFile), the romfs
overlay checks, the audio pacing waits, the motion, ASTC and device fault locks. plat_cpu_usable and
plat_commit_info get Linux versions; plat_cpu_count counts the machine's processors on both. dpi_probe.c becomes
dpi_probe_win.c.
4. assume_focus defaults to 1 as the PR has it (a load interrupted by a focus loss can stop for good) and stays live,
with dev's Game tab row.
5. The frame limits 40 and 45 join dev's list. The BC 3D storage fallback for Vega only runs with
TOTK_BLOCK_VIEWS_3D=1, since dev makes 3D BC images without block views by default.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The present fits the game's picture into the largest centred rectangle of its own aspect ratio and clears the rest to
black (gfx_fit_rect, through both the blit and FSR), so a 16:9 game on the Deck's 16:10 screen is no longer stretched;
picture_fit = stretch keeps the old fill. probe-window checks the bars as well as the picture.
device_profile = auto|desktop|deck: on a Steam Deck (the firmware's Valve Jupiter or Galileo board, or SteamDeck=1) the
keys totk.ini does not set default to fullscreen, a 1280x800 window, a 1280x720 game resolution, the game's own scene
scale, vsync and a 40 fps limit; the environment and totk.ini still win. These are starting points until measured on
the device (docs/tester-guide.md, Steam Deck).
Both stick clicks (L3 + R3) step the performance overlay as F10 does, for a controller with no keyboard. The menu offers
1280x720 and 1600x900 game resolutions and 40, 45 and 90 fps limits.
Shared runtime code now goes through runtime/platform/platform.h, implemented by platform/win32.c and a new
platform/linux.c: futex locks, a userfaultfd and PAGEMAP_SCAN write watch, signal-based async preemption, our own
fiber switch, and a SIGSEGV handler for the thaw and crash hooks. The window, input, menu and software keyboard get
SDL3 back ends beside the Win32 ones, with the swapchain (gfx_present.c) and input merging (input.c) shared. SHA-256
replaces BCrypt, ELF builds get their own override sections, and the build tools gain Linux branches.
On Linux the selftest and the gfx-abi, astc, nvn and window probes pass. probe-vkmem still fails: imported guest
memory cannot be write-watched on Linux, which the shadow buffers in vk_memory.c will address.
