forked from Ports/goldeneye-pc-port
Remove the legacy always-grab mouse mode (D192 + D239)
Per the M-82/M-106 user decision: click-to-lock is now the only cursor
capture mode. Port-only deletion, no game-code touch:
port/src/input.c drop mouseCaptureMode + Input.MouseCaptureMode key;
simplify reconcileGrab/notifyClick/releaseCapture/
aimGepdCompute guards; delete the !haveAbs relative
P-controller menu path and its dead state (menuEst/Tgt,
menuCursorStep, MENU_P_GAIN/EST_DELTA/MOUSE_TO_PX);
drop the unused inputMouseCaptureActive() export
port/include/input.h update WI-1 comment, remove the dead declaration
port/src/optionsoverlay.c remove the 'Mouse capture' toggle row + labels
Existing ini files that set Input.MouseCaptureMode are ignored (config layer
skips unknown keys). Closes D192 (outer grid cells unreachable under mode 0)
and D239 (always-grab parity) by removing the bugged path rather than
patching it.
This commit is contained in:
James Dansereau committed
1 parent
d3d968bc0e
commit
cc9068bfa1
4 files changed
+28
-101
No files matched your search
@@ -400,7 +400,7 @@ covers D24–D69; the log continues in §H (D32 procedure, D70–D121).
|
||||
| D199 | **Phase-3 software audio mixer: macro-swap `aXxx` opcode execution + reverse-engineered `aSetBuffer` persistent-context semantics (`port/src/mixer.c`, `port/include/mixer.h`, `include/PR/abi.h`).** The RSP audio ucode (`aspMain`) that would normally execute GE's acmd list never runs on PC (`port/src/ucode.c`); adapting the Perfect Dark PC port's macro-swap trick (`docs/dev/AUDIO-PLAN.md`), `include/PR/abi.h` now `#include`s `port/include/mixer.h` under `#ifdef PORT`, which redefines every `aXxx` macro to call an `Impl` function in `mixer.c` immediately against a small software "DMEM" scratch buffer, instead of packing RSP command words for later execution. GE uses the classic IDO libaudio ABI (verified against every call site in `src/libultra/audio/*.c` + `src/libultrare/audio/{env,reverb}.c`), not PD's differently-shaped "naudio New" ABI — DSP math (ADPCM decode, linear resample, linear envelope mix) is the same Nintendo/SGI ucode PD's `mixer.c` already ported; only the ABI/addressing layer is GE-specific and new here. Several opcodes (`aADPCMdec`, `aResample`, `aEnvMixer`, `aLoadBuffer`, `aSaveBuffer`) take only a state/DRAM pointer — their DMEM source/dest addresses and byte counts come from the most recent `aSetBuffer` call(s), which there is no RSP disassembly to check against; the persistent-context shape (`sCtx.{in,out,count,dryR,wetL,wetR}`) was reconstructed purely from reading every `aSetBuffer`+opcode call-site pair across `resample.c`/`load.c`/`reverb.c`/`mainbus.c`/`save.c`/`env.c` (see the field comments on `sCtx` in `mixer.c:52-82`). `aSegmentImpl` is a no-op — GE's audio DRAM addresses are already resolved via `osVirtualToPhysical` before reaching the mixer (see D198), so segment/base never factor into DMEM addressing here. **Risk:** the `aSetBuffer` context reconstruction is an inference, not a verified spec — if a call site this session didn't audit sets the context differently, audio for that path will mix from the wrong DMEM offsets. **Verified:** `-level_09` now runs full music + SFX 120s+ crash-free (post-D200 fix); no cross-level or opcode-level audio-correctness verification done yet (no golden-audio comparison tooling exists). | LANDED (`port/src/mixer.c`, `port/include/mixer.h`, `include/PR/abi.h`) — functional on `-level_09`, context-inference risk noted, needs a wider level sweep |
|
||||
| D200 | **`-level_09` segfault: reverb's `ALDelay.input/output` are u32 — `-d->output` zero-extends to a +4GB pointer offset on 64-bit (D3x class, FIXED).** `src/libultrare/audio/reverb.c` back-references the delay ring as `&r->input[-d->output]`; on N64 (s32 `ptrdiff_t`) the u32 negation wraps to a small negative index, on PC x86-64 it zero-extends to +4294967136 samples → `_loadBuffer`/`_saveBuffer` write 13–52KB wild, trampling the delay array / `r->base` / adjacent heap in a self-propagating loop until unmapped memory. Fixed with `(s32)` negation casts at 5 sites (PD ground truth `n_reverb.c` does exactly this); ramalign line gets `(s64)`. Verified: `-level_09` runs 120 s+ crash-free, DRAM guard window over the FX region sees zero OOB writes. | FIXED — 5-line cast in reverb.c (this session) |
|
||||
| D196 | **OS mouse cursor stays visible after closing the F10 options overlay in click-to-lock mode (M-49, user playtest).** `Input.MouseCaptureMode=1`. Open F10 overlay → `optionsOverlayToggle()` (`optionsoverlay.c:391`) calls `inputSuspendForOverlay()` which forces `SDL_ShowCursor(SDL_ENABLE)` + drops the grab. While open, `inputComputePad(0)` early-returns at `input.c:512` (overlay owns controller 0) **before** `reconcileGrab()` / any cursor-visibility call. On close: the next poll runs `reconcileGrab(menuMode)` (`input.c:522`) which re-grabs + hides the cursor **only if `captureArmed && !menuMode`** — i.e. only if you had already clicked-to-lock in a stage before opening F10. If you opened the overlay from a menu, or in a stage you hadn't clicked-locked yet, `want` computes 0, `mouseGrabbed` stays 0, and **nothing calls `applyCursorVisibility()`** — so the cursor `inputSuspendForOverlay()` made visible never gets re-hidden (correct free-but-focused state per `applyCursorVisibility()` `input.c:842-846` is *hidden*). **Fix (port-only, ~1 line):** call `applyCursorVisibility()` right after the `reconcileGrab(menuMode)` at `input.c:522` (self-heals every poll once the overlay-open early-return stops firing), or add an `inputResumeFromOverlay()` that runs `reconcileGrab` + `applyCursorVisibility` and call it from `optionsOverlayToggle()` on close. D180/D184/D165 input lineage. Minor. | **FIXED (`6e758f1d`, merged to `main`) — the first option above was applied:** `applyCursorVisibility()` now runs right after `reconcileGrab(menuMode)` in the controller-0 poll, so once the overlay-open early-return stops firing the cursor visibility self-heals on the next poll. Status cell was left stale at OPEN; corrected M-105. |
|
||||
| D192 | **Front-end mission/level-select grid pointer still can't reach the outer cells — but only under `Input.MouseCaptureMode=0` (legacy always-grab) (M-49, user playtest).** D169 was marked FIXED (M-33) by replacing the hard-coded 320×240 pointer clamp with the live `getPlayer_c_screenwidth/height/left/top()` rect; the feel-check was flagged "owed" on both D169 and D180 and never done. It now reproduces: with `MouseCaptureMode=0` the menu pointer runs the relative-delta P-controller path (`port/src/input.c:659-690`), which clamps target+estimate to `getPlayer_c_screen*` — but that accessor returns `g_CurrentPlayer->c_screenwidth` (`src/game/bondview.c:882`), which in the front end is the ~320×240 stage viewport, **not** the front end's actual 440×330 (`front.c:8570` `viSetViewSize(440,330)`). So the effective clamp is still ~300/220 while the mission-select grid's outer split points sit at 317 / 235.5 (`front.c:516/519/3180/3194`) — outer columns + bottom row unreachable, P-controller winds up and never settles. `MouseCaptureMode=1` (the shipped default, click-to-lock) writes `cursor_h_pos`/`cursor_v_pos` directly from the absolute OS cursor (`input.c:629-657`) and *feels* fine, though it shares the bad `hiH` so the last few px at the right/bottom edge may still be short. **Not a v0.1.0 blocker** — default mode is acceptable, always-grab is opt-in via INI, front-end roughness is already in the release notes. **Fix (port-only, small):** in the `menuMode` branch, when `current_menu` is a front-end menu use the real front-end rect (hard-code `front.c`'s cursor clamp `[20,420]×[20,310]`, or read the front-end viewport global) instead of routing through `g_CurrentPlayer`. Confirm with one `GE_INPUTLOG=1` capture in mission-select — sweep the mouse to each corner, watch where `cursor=(x,y)` plateaus. D165 · D169 · D180 lineage. | OPEN — root-caused, not fixed (M-49) |
|
||||
| D192 | **Front-end mission/level-select grid pointer still can't reach the outer cells — but only under `Input.MouseCaptureMode=0` (legacy always-grab) (M-49, user playtest).** D169 was marked FIXED (M-33) by replacing the hard-coded 320×240 pointer clamp with the live `getPlayer_c_screenwidth/height/left/top()` rect; the feel-check was flagged "owed" on both D169 and D180 and never done. It now reproduces: with `MouseCaptureMode=0` the menu pointer runs the relative-delta P-controller path (`port/src/input.c:659-690`), which clamps target+estimate to `getPlayer_c_screen*` — but that accessor returns `g_CurrentPlayer->c_screenwidth` (`src/game/bondview.c:882`), which in the front end is the ~320×240 stage viewport, **not** the front end's actual 440×330 (`front.c:8570` `viSetViewSize(440,330)`). So the effective clamp is still ~300/220 while the mission-select grid's outer split points sit at 317 / 235.5 (`front.c:516/519/3180/3194`) — outer columns + bottom row unreachable, P-controller winds up and never settles. `MouseCaptureMode=1` (the shipped default, click-to-lock) writes `cursor_h_pos`/`cursor_v_pos` directly from the absolute OS cursor (`input.c:629-657`) and *feels* fine, though it shares the bad `hiH` so the last few px at the right/bottom edge may still be short. **Not a v0.1.0 blocker** — default mode is acceptable, always-grab is opt-in via INI, front-end roughness is already in the release notes. **Fix (port-only, small):** in the `menuMode` branch, when `current_menu` is a front-end menu use the real front-end rect (hard-code `front.c`'s cursor clamp `[20,420]×[20,310]`, or read the front-end viewport global) instead of routing through `g_CurrentPlayer`. Confirm with one `GE_INPUTLOG=1` capture in mission-select — sweep the mouse to each corner, watch where `cursor=(x,y)` plateaus. D165 · D169 · D180 lineage. | CLOSED — the buggy mode 0 was removed entirely in the v0.2.0 prep pass (see D239); click-to-lock is now the only capture mode, so the unreachable-cells path no longer exists |
|
||||
| D221 | **SELECT FILE screen: the mouse hit-box for a file slot is vertically offset from its visible box — you have to click *below* a file to select it, hovering directly over it doesn't (M-87, user QA, default `MouseCaptureMode=1`).** Different symptom from D192 (D192 is an unreachable-outer-cells *clamp range* bug under legacy mode 0; this is a per-row hit-test/highlight *offset* bug under the shipped default mode 1). | **FIXED (M-91) — root cause was NOT a coordinate/origin mismatch: it's a compiler stack-layout dependency in `interface_menu05_fileselect` (`front.c`).** The hit-test projects each wallet's model extents via `projectRectCornersTo2D`, which takes `{min,max}` `coord2d` *pairs* — but the file-select caller passed `&xmin, &ymin` (four separate f32 locals), relying on the N64 compiler laying out the max adjacent to each min. On PC (declaration-order locals) `arg1->f[1]` reads **ymax** as an X coordinate and `arg2->f[1]` reads an unrelated stack float (observed: `2.25734`, later `nan`) — so the vertical hit band collapsed to a ~14 px strip at the bottom edge of each wallet, sometimes NaN (never selectable that frame). Exactly "click below the file." The other caller (`objective_status.c:525`) passes real `coord2d` structs and was always fine. Fix: pass explicit `{xmin,xmax}`/`{ymin,ymax}` pairs under `#ifdef PORT` (identical values to what the N64 binary used; N64 path untouched). Verified headless: pre-fix A-press at cursor (154.7,127.8) over folder 0 never selected; post-fix same press selects folder 0 and advances. **Human mouse-playtest (this session): confirmed clicking directly over each visible file wallet selects it immediately, no aiming low required; consistent across all slots and the Copy/Erase icons; no crash.** Full details in §H "D221 — M-91". |
|
||||
| D222 | **High `Video.FovScale` breaks culling — NPCs and some world objects stop rendering near the screen edges (M-87, user QA).** Split out of D211's noted residual: `currentPlayerSetCameraScale()` / the game's frustum-cull and screen↔world math still run at the **nominal, unscaled** fovy while the actual render projection is widened by `portFovScale` (`fr.c:737`) — so objects that are on-screen in the widened view but outside the nominal-FOV frustum get culled before they reach the renderer. Confirmed **not cosmetic** — a real, noticeable functional regression at high FovScale, not just "culls a hair early." | **FIXED, awaiting visual verification (M-121).** Root cause traced one step further than the original write-up: `currentPlayerSetCameraScale()` (`game/bondview.c`) derives both the frustum-cull plane normals (`c_cameratopnorm`/`c_cameraleftnorm`) *and* the fog/LOD distance-visibility-fade scale (`c_scalelod`/`c_lodscalez`, consumed by `chrobjFogVisRangeRelated()` et al. in `propobj.c`) from `c_perspfovy`, which every `viSetFovY`/`viSetAspect`/`viSetFov`/`viSetZRange` call in `fr.c` was setting from the **nominal** `g_ViBackData->fovy` — never the `portFovScale`-widened value D211 already computes for the actual render projection two lines away in `viSetupCurrentPlayerView`. Fix: factored the existing widen-FOV math out of `fr.c` into `f32 portScaleFovY(f32 fovy, s32 isTitleScreen)` (`port/src/video.c`, D222 — identical logic, same `LEVELID_TITLE` guard, no game-code duplication) and fed it into all 4 `currentPlayerSetPerspective()` call sites via a small `#ifdef PORT` local helper in `fr.c` (`frCullFovY`), same as the existing D211 projection-matrix chokepoint now also calls the shared helper instead of its own inline copy. Identity (bit-for-bit no game-code-visible change) at `FovScale=100` by construction — `portScaleFovY` returns `fovy` unchanged whenever `portFovScale == 1.0f`. Audited per the original risk note: `c_cameratopnorm`/`c_cameraleftnorm`/`c_scalelod`/`c_lodscalez` are consumed only in `propobj.c`'s fog-visibility-fade math and `bondview.c`'s own screen-space transform — no AI-visibility/awareness call sites found reading these fields, so `portFovScale` still only touches rendering-adjacent visibility, not NPC behavior. Rebuilt clean, crash-free at `FovScale=150` on `-level_33` (Dam). `bunker1` golden framediff was inconclusive in this dev box — the *unmodified* baseline build also fails it by a similar or larger margin (confirmed via an A/B stash/rebuild), matching the documented pre-existing frame nondeterminism (`porting-notes.md` §E), not a regression from this change. **Needs a human's eyes**: does high-`FovScale` screen-edge NPC/object culling actually look fixed now. |
|
||||
| D223 | **QoL ask: mouse-wheel weapon cycling should be directional like a normal PC shooter — wheel up = next weapon, wheel down = previous — instead of both directions cycling forward (M-87, user QA).** **Root-caused, port-only fix, no game-logic change needed** — GE's engine already has separate forward/backward weapon-cycle signals: `bondview2.c` computes `moveData.weaponForwardOffset = edge(invButtons) && !(shootButtons held)` and `moveData.weaponBackOffset = (invButtons held) && edge(shootButtons)` (`bondview2.c:5338-5347`, the classic N64 "hold A, tap Z to cycle backward" trick). Default control scheme (the `else` branch used unless a Domino/Goodhead/Galore/Plenty preset is active, `bondview2.c:5177-5179`): `invButtons = A_BUTTON` (= port `GE_CONT_A`, `input.c:86`), `shootButtons = Z_TRIG` (= port `GE_CONT_G`, `input.c:88`, the fire button). `moveData.triggerOn` is explicitly suppressed while `invButtons` is held, so holding A never causes an accidental shot when the Z edge lands. The port's `inputPostWheel()` (`input.c:977`) currently does `if (notches < 0) notches = -notches` — **discards wheel direction** — and only ever synthesizes a bare `GE_CONT_A` pulse (`wheelPulse`, `input.c:631-634`), i.e. always "forward." | **FIXED (M-105, `port/src/input.c`) — directional wheel cycling implemented per the plan below.** Wheel-up keeps the existing 2-poll `A` pulse (`weaponForwardOffset`: fresh A edge, Z released). Wheel-down runs a 2-poll backward sequence: poll 1 presents `A` only, poll 2 presents `A`+`Z_TRIG` — the fresh-Z-edge-while-A-held combo `weaponBackOffset` requires (`bondview2.c:5337-5340`); ordering matters because the edge is computed against the game's own previous poll. `moveData.triggerOn` (`bondview2.c:5419`) requires A to be released, so the synthesized Z edge can never fire a shot. Roles are stable: the port forces `CONTROLLER_CONFIG_HONEY` (`bondview.c:1484`), whose scheme gives `invButtons=A_BUTTON`/`shootButtons=Z_TRIG` — the same roles the pre-fix forward pulse already relied on. Known limitation (pre-existing, not a regression): while RMB aim is held the game flips `controldef` to KISSY (`bondview2.c:6106-6112`), under which *neither* direction cycles — exactly as the old forward-only pulse behaved in that state. Owes a human play-test (wheel up = next weapon, wheel down = previous, no accidental shots). Plan: keep `wheelPulse` (or a new `wheelPulseFwd`) for wheel-up as today; add a `wheelPulseBack` path for wheel-down that instead holds `GE_CONT_A` across ≥2 polls while presenting a fresh `GE_CONT_G` edge partway through (mirroring the invButtons-held + shootButtons-edge combo) — sequence matters (A must already read "held" `oldbuttons`-wise before G's edge, per `weaponBackOffset`'s check order). Must confirm which N64 control preset (`controldef`) the port's save data actually carries — `invButtons`/`shootButtons` differ under KISSY/GOODNIGHT/SOLITARE/etc; if the port doesn't force one, the synthesized combo needs to match whatever's active, or the port should just force the default (HONEY-equivalent) preset since its own `Input.Bind` system already replaces N64-style scheme selection. Port-only, `#ifdef PORT` in `input.c`, no `src/` game-logic touch. **M-87: PD-PC-port precedent checked (user asked what PD did about N64 control presets).** PD does **not** route mouse/gamepad through the N64 preset system at all — it defines its own logical control-key layer (`CK_*` in `port/src/input.c`/`input.h`, e.g. `CK_DPAD_L`/`CK_Y`) fully decoupled from the N64 controller-config enum, and even treats mouse-wheel-up/-down as **two independent bindable virtual keys** (`VK_MOUSE_WHEEL_UP`/`_DN`, defaulted to distinct `CK_*` actions) rather than one "wheel = cycle" event — exactly the shape of the fix this row wants. PD's `controldef` field is hardcoded (`player.c`/`playermgr.c` `controldef = 2`), not left to the original in-game control-style picker. **This GE port already has the equivalent layer for this purpose: D214's `Input.Bind` system.** Recommendation for D223 (and the user's broader ask — N64 presets aren't meaningful for mouse/keyboard, and modern-gamepad (Xbox/PS) support should be a first-class port concept, not routed through N64 presets either): add two new `Input.Bind`-able logical actions (e.g. `IA_WEAPON_NEXT` / `IA_WEAPON_PREV`) that synthesize the invButtons/shootButtons combos under the hood, default-bound to wheel-up/-down (keyboard/mouse) and left open for a future bumper/shoulder-button default under real gamepad support; and have the port force a single fixed `controldef` (matching PD's approach) so the synthesis target never depends on the original N64 control-style menu. That menu itself becomes a candidate for hiding/no-op in a future QoL pass once `Input.Bind` fully supersedes it — not proposed as a change here, just noted as the natural conclusion. **M-87 — D194 gives a concrete answer for *which* preset: `CONTROLLER_CONFIG_SOLILine truncated
|
||||
@@ -517,7 +517,7 @@ covers D24–D69; the log continues in §H (D32 procedure, D70–D121).
|
||||
| D236 | **Surface 1: 2D billboard trees render as a wall/sheet of tree texture instead of discrete camera-facing tree sprites (M-106, user QA report).** Suspects: missing billboard orientation (quads coplanar in world space) or UV/texture-rect setup mapping the whole sheet per quad. Distinct from D176(b)'s painted tree-line backdrop. Logged in `GRAPHICS-BACKLOG.md`. | OPEN — not investigated |
|
||||
| D237 | **QoL ask (M-106, user QA): F10 options overlay — make it scrollable with the mouse wheel, expose more settings into it (e.g. screen-flash / no-hit-flash `Game.NoHitFlash`, and other easily-exposed config keys), and organise rows by category (mouse settings together, video together, etc.).** The overlay (`port/src/optionsoverlay.c`) already renders over the registered `config.c` option list; what's missing is wheel-scroll nav, a broader row set, and grouping headers. Cross-ref `OPTIONS-MENU-PLAN.md` §3 (v1 minimum set) + QOL-INVENTORY "PD has, GE lacks". | OPEN — not designed; port-only |
|
||||
| D238 | **QoL ask (M-106, user QA): mouse sensitivity rework toward normal PC-shooter feel.** Three parts: (1) a *separate* RMB aim-mode sensitivity in addition to hipfire turn; (2) ideally ONE single master mouse-sensitivity setting driving both, **linked by default**, with an option to set them independently later (today `Input.MouseAimSpeed` and `Input.MouseTurnSpeed` are two independent keys, defaults 16/100 — see `input.c:188-190`); (3) up/down should feel mostly the same as left/right (`Input.MouseYScale` exists but the axis asymmetry in the gain constants `AIM_GAIN`/`MOUSE_TURN_GAIN` + smoothing path is the likely culprit). User's reference for "feels better": GEPD Mouse Injector. Lump with the overall mouse/input fixes (D194/D165/D166 lineage; SOLITAIRE natural-pitch scheme switch may subsume part of this — see D166 M-87 note). | OPEN — not designed; port-only (`port/src/input.c` + `config.c`) |
|
||||
| D239 | **QoL ask (M-106, user QA): click-to-lock vs always-grab parity.** User: make click-to-lock the default *if it isn't already* — it IS: `mouseCaptureMode = 1` is the shipped default (`input.c:185`). The real content: "always grab" feels bad on the file-select menu, not 1:1 with click-to-lock; if making them feel identical is overly complicated, **drop always-grab entirely and remove the setting**. This re-confirms the existing M-82 user decision to rip out `MouseCaptureMode=0` (see `docs/BACKLOG.md` "M-82 playtest feedback" + D192: mode 0's P-controller path can't reach the outer front-end grid cells — a known mode-0-only defect). Recommendation on this new report: take the user's fallback — remove mode 0 and the `Input.MouseCaptureMode` key, keep click-to-lock only. | OPEN — supersedes/re-confirms the M-82 always-grab removal item; port-only |
|
||||
| D239 | **QoL ask (M-106, user QA): click-to-lock vs always-grab parity.** User: make click-to-lock the default *if it isn't already* — it IS: `mouseCaptureMode = 1` is the shipped default (`input.c:185`). The real content: "always grab" feels bad on the file-select menu, not 1:1 with click-to-lock; if making them feel identical is overly complicated, **drop always-grab entirely and remove the setting**. This re-confirms the existing M-82 user decision to rip out `MouseCaptureMode=0` (see `docs/BACKLOG.md` "M-82 playtest feedback" + D192: mode 0's P-controller path can't reach the outer front-end grid cells — a known mode-0-only defect). Recommendation on this new report: take the user's fallback — remove mode 0 and the `Input.MouseCaptureMode` key, keep click-to-lock only. | CLOSED — executed in the v0.2.0 prep pass (port-only): `mouseCaptureMode` + the config key, `reconcileGrab`'s legacy branch, the `!haveAbs` relative menu path and its now-dead P-controller state (`menuEst/TgtH/V`, `menuCursorStep`, `MENU_P_GAIN`/`MENU_EST_DELTA`/`MENU_MOUSE_TO_PX`), the F10 "Mouse capture" row, and the unused `inputMouseCaptureActive()` all removed from `port/src/input.c` / `optionsoverlay.c` / `port/include/input.h`. Click-to-lock is the only mode; existing ini files setting the old key are ignored. Closes D192 with it |
|
||||
| D240 | **Player gunshot SFX timing/cadence reportedly does not match the N64 original's rate (M-106, user QA report).** Static trace only (no ROM/build/display in this worktree). Weapon fire re-triggers its SFX through `bondwalkItemGetSoundTriggerRate()`/`bondwalkItemGetSound()`, gated on `g_GlobalTimer` (`src/game/gunfire.c:3246-3286`: `handptr->field_A4C = bondwalkItemGetSoundTriggerRate(var_s1) + g_GlobalTimer`), alternating between two per-hand `ALSoundState` slots (`audioHandle`/`field_A48`, same block) so a fast-firing weapon's report can overlap itself once before being retriggered. `g_GlobalTimer` advances by `g_ClockTimer = speedgraphframes` every tick (`src/game/lv.c:1023,1037`), and `speedgraphframes` is set from `deltaFrames` in `updateFrameCounters()` (`src/game/frametiming.c:64-76`) — the exact tick-delta plumbing already investigated (and partly fixed) under **D155** (catch-up-spiral clamp, same file), **D186** (`Video.FpsCap` sim-coupling clamp), **D193/D209** (AI-locomotion timing keystone — D209 the actual root cause, a 64-bit union-aliasing bug, now fixed and merged), and **D204** (audio pipeline running ~2% below real time forever, fixed by padding silence at the DAC). Since D209 and D204 both merged before this report, the SFX-cadence complaint is either (a) a genuinely distinct, audio-specific residual downstream of those fixes — e.g. a mismatch between the sim-tick-gated *trigger* (above) and the software mixer's own playback clock (`port/src/audio.c:93,155,221-222` — the synth produces samples at a measured ~21600/s against the 22050 Hz output device, the same gap D204 had to compensate for elsewhere) that specifically desyncs how *often* a shot's sample starts rather than the absolute wall-clock rate D204 measured, or (b) a stale pre-D209/pre-D204 build report. Per-weapon rate constants (`AutomaticFiringRate`/`SingleFiringRate`/`SoundTriggerRate`, `src/game/gun.h:60-82`, values in `assets/obseg/gun/*/gunWeaponStat.inc.c`) are plain compiled C literals, not ROM-serialized data, so no pointer-width/ABI reconciliation issue applies here. | **OPEN — not root-caused; static call-site tracing only, no runtime verification possible in this environment.** Confidence LOW-MEDIUM that this is a *new* bug distinct from the D155/D186/D193/D204/D209 timing-keystone family (all of which gate the identical `deltaFrames→speedgraphframes→g_ClockTimer→g_GlobalTimer` chain this SFX trigger consumes). Raise confidence by: (1) confirming the user's build/commit postdates the D209 merge; (2) a `GE_AUDIOTRACE`-style capture logging the tick (`g_GlobalTimer`) and/or wall-clock timestamp of consecutive same-weapon fire-SFX requests during sustained auto-fire (AK47/Klobb, `AutomaticFiringRate=0x03`), diffed against the weapon's rate constant and against N64 reference footage's frame-count between shots. |
|
||||
| D241 | **Player gunshot SFX goes silent under some conditions — reported on Bunker with the alarm sounding, "or some other factor" — but only for PP7 and AK47, Klobb unaffected (M-106, user QA report, concrete repro).** This is very likely **D207 finally reproduced.** D207 (M-77) root-caused that GE's SFX player has a hard **8-voice cap** (`MUSIC_SFX_SEQ_MAYBE_MAX_SOUNDS`, `src/music.c:76`) and that D206's fix made the alarm klaxon (`ALARM3_SFX`=163, triggered from `handle_alarm_gas_timer_calldamage()`, `src/game/propobj.c:14457`) a genuine **infinite ADPCM loop** that now legitimately occupies one of those 8 voices for the alarm's whole duration; the manual preemption scan (`snd.c:~347-392`) refuses to steal any *owned* LOOPED voice (the M-65 carve-out only exempts *ownerless* loops), so once 8/8 voices are held, a new one-shot request is silently dropped via `sndDisposeSound` (`snd.c:391`). D207's own M-77b session built a `GE_FORCEALARM=1` BUNKER1 harness and could **not** reproduce audible drops (`[D207-DROP]=0`), and explicitly left as "owed": *"needs a real repro from the user: which level, which weapon/situation."* This report supplies exactly that (Bunker, alarm). **Investigated why PP7/AK47 and not Klobb, inconclusive at the code level:** Klobb (`ITEM_SKORPION` — confirmed GE's internal name for the Klobb via `src/game/player.c:576`, `skorpion_stats` in `assets/obseg/gun/skorpion/gunWeaponStat.inc.c`) and AK47 (`ak47_stats`, `assets/obseg/gun/ak47/gunWeaponStat.inc.c`) share the **same** `AutomaticFiringRate=0x03` (fast auto), while PP7 (`wppk_stats`, `assets/obseg/gun/wppk/gunWeaponStat.inc.c`) is semi-auto only (`AutomaticFiringRate=0xFF`) — so a naive "fires faster ⇒ more self-inflicted voice contention" theory does not cleanly explain grouping PP7 with AK47 against Klobb. All three weapons' fire SFX (`GUN_B1_MGUN3_3_SFX`=Klobb, `GUN_B2_HEAVY_SFX`=PP7, `GUN_B4_BOLTACTION_SFX`=AK47 — `src/bondconstants.h:2277-2280`) go through the identical one-shot, priority-0x40 `sndPlaySfx` path (`gunfire.c:3246-3286`); no per-weapon distinction exists in the trigger or priority *code*. A real distinction, if one exists, most likely lives in the **sample bank data itself** (per-sample envelope/decay length — a longer-tailed sample stays `PLAYING` and stealable/held longer, changing its odds in the preemption scan) — that data is ROM-derived binary content, not inspectable without the extracted ROM (`./data/`, absent in this worktree). Confirmed the voice-allocation/preemption code is unmodified `src/snd.c` game logic, not a `port/` mixer bug: `port/src/mixer.c`/`port/src/audio.c` implement DSP synthesis and device output only (per D199), with no SDL `Mix_*`-style channel-priority layer in the port to have introduced a new bug. Per AGENTS.md non-negotiable #2, any real fix belongs in D207's already-designed (reverted, M-77b) last-resort LOOPED-preemption pass in `snd.c`, not in `port/`. | **OPEN — not newly root-caused; high confidence this is D207 reproduced, not an independent bug.** Recommend folding this repro into D207 (or closing D241 as a duplicate once D207 is reopened) rather than tracking separately. Next: re-run M-77's `GE_FORCEALARM=1` harness on `-level_09` with scripted PP7 and AK47 fire (not just generic fire) against Klobb as a control, watching `g_sndAllocatedVoicesCount` / the (currently reverted) `[D207-DROP]` counters to see whether the 8-cap is actually hit for two of the three weapons and not the third — or whether it is really the sample-envelope-length distinction above. No runtime verification possible in this environment (no ROM/display). |
|
||||
| D242 | **Player-death sequence UX regression vs N64 original: PC requires an LMB click to proceed to the mission-failed/file-select screen; user recalls N64 auto-plays 3 death-camera angles then transitions with no input needed (M-106, user QA report).** **The 3-angle auto-replay and its no-input auto-transition both exist, unmodified, in the decomp — confirmed, not a design difference removed for the port.** `bondviewSetCameraMode(CAMERAMODE_DEATH_CAM_SP)` (`src/game/bondview2.c:901-1010`) calls `pickDeathCameraAngles()` (`bondview2.c:641-782`, picks a fresh random valid camera angle each call) to stage each replay; when it returns 0 — no further valid angle found — the code calls `bossRunTitleStage()` directly, and the source comment at `bondview2.c:1006-1007` literally reads *"...or when the three death replays are finished."* The 3-cycle count is driven by `bondviewAdvanceCameraMode()` (`bondview2.c:1041-1078`): `CAMERAMODE_DEATH_CAM_SP` → `CAMERAMODE_DEATH_CAM_MP` → `camera_mode++`, looping back to `DEATH_CAM_SP` while `camera_mode < CAMERAMODE_SWIRL` (three iterations). Each individual replay's own advance is driven purely by animation/timer state (`bondview2.c:1467-1490`): the `g_CameraAfterCinema` flag that `bondviewAdvanceCameraMode()` acts on is set automatically once `modelGetAnimFrame(bodyModel) >= modelGetAnimEndFrame(bodyModel)`, or after a `camera_transition_timer >= 180.0f` tick-timeout fallback when there is no body model — **no button check in that branch; fully automatic.** **The button-press the user is hitting is a real, intentional N64 skip-ahead shortcut, not a port-added gate:** the same code block (`bondview2.c:1483-1489`) *also* fires the identical advance immediately on `(buttons & ~oldbuttons & (CONT_A | B_BUTTON | Z_TRIG | START_BUTTON))` whenever `bonddead && redbloodfinished && deathanimfinished` — i.e. on real N64 hardware, pressing A/B/Z/Start at any point during a death replay skips straight to the end, by design. **On the port, LMB (mouse fire) is mapped to `GE_CONT_G`, which is Z_TRIG** (`port/src/input.c:664-665`: `(mb & SDL_BUTTON(SDL_BUTTON_LEFT)) ... button \|= GE_CONT_G`; binding table `input.c:351`: `{"Z",GE_CONT_G}`) — exactly one of the four original skip buttons. So an LMB click during the death sequence is GE's own original cutscene-skip input, faithfully wired through the port's control remap, not a port-invented "click to continue" prompt. **What this investigation could not determine** (no build/runtime access in this worktree): whether the *automatic*, no-input path actually completes on PC in a reasonable time. `camera_transition_timer` accumulates via `g_GlobalTimerDelta` (`bondview2.c:1470,1493`), which is set from the same `g_ClockTimer`/`speedgraphframes`/`deltaFrames` chain flagged in D240 above and investigated under D155/D186/D193/D204/D209 — if any residual in that chain stalls or mis-scales specifically in this state, the auto-advance could take far longer on PC than on N64 (or effectively never complete before the player gives up and clicks), which would make an LMB click *feel* mandatory even though the ground-truth logic never requires one. | **NOT A PORT-LOGIC BUG as far as static analysis can tell.** Confidence HIGH that the LMB-click skip path is faithful original behavior (Z_TRIG-mapped, exists unmodified in `bondview2.c`), not a defect to remove. Confidence LOW (untested) on whether the no-click automatic path is actually healthy on PC. Needs a human playtest: die, then **deliberately touch no input** during the death sequence and time whether/how long until the mission-failed screen appears on its own. If it never arrives without a click, the real bug is a `g_GlobalTimerDelta`/`camera_transition_timer` stall in the D240 clock family — cross-reference D240 — not a wrongly-added input gate, so there is still no `#ifdef PORT` skip-gate to remove per AGENTS.md #2. No runtime verification possible in this environment (no ROM/display). |
|
||||
|
||||
@@ -44,15 +44,12 @@ unsigned inputComputePad(int idx, signed char *stick_x, signed char *stick_y);
|
||||
* disabled in config. */
|
||||
void inputSetMouseGrab(int on);
|
||||
|
||||
/* WI-1 click-to-lock cursor capture (Input.MouseCaptureMode = 1). The host
|
||||
* event pump calls inputNotifyClick() when a mouse button goes down inside the
|
||||
* game window (arms + locks the cursor), and inputReleaseCapture() when ESC is
|
||||
* pressed (frees it; returns 1 if it consumed the key). inputMouseCaptureActive()
|
||||
* is true when capture mode is on and the cursor is currently free -- the pump
|
||||
* uses it to decide whether a click should be swallowed rather than passed on. */
|
||||
/* WI-1 click-to-lock cursor capture. The host event pump calls
|
||||
* inputNotifyClick() when a mouse button goes down inside the game window
|
||||
* (arms + locks the cursor), and inputReleaseCapture() when ESC is pressed
|
||||
* (frees it; returns 1 if it consumed the key). */
|
||||
void inputNotifyClick(void);
|
||||
int inputReleaseCapture(void);
|
||||
int inputMouseCaptureActive(void);
|
||||
|
||||
/* F10 options overlay: force the OS cursor free + visible while the overlay
|
||||
* owns the mouse. Safe to call every poll. */
|
||||
|
||||
+22
-90
@@ -265,9 +265,6 @@ extern s32 lvlGetCurrentStageToLoad(void);
|
||||
#define MENU_CURSOR_HI_V 220.0
|
||||
#define MENU_CURSOR_MID_H 160.0
|
||||
#define MENU_CURSOR_MID_V 120.0
|
||||
#define MENU_P_GAIN 6.0 /* stick = GAIN*(target-est); 0.075*GAIN<1 => no overshoot */
|
||||
#define MENU_EST_DELTA 1.0 /* deltaEst per poll (front.c integrates ~1 tick/frame) */
|
||||
#define MENU_MOUSE_TO_PX 1.0 /* device px -> virtual cursor px (x MenuPointerSpeed/100) */
|
||||
|
||||
static void applyGrab(int want);
|
||||
static void reconcileGrab(int menuMode);
|
||||
@@ -281,15 +278,15 @@ static SDL_GameController *pads[MAX_PADS];
|
||||
static int mouseEnabled = 1;
|
||||
static int mouseGrabbed = 1; /* released while the window is unfocused */
|
||||
|
||||
/* WI-1: Quake-style click-to-lock cursor capture.
|
||||
* MouseCaptureMode 0 (default) = legacy: cursor is grabbed whenever the
|
||||
* window has focus and MouseEnabled is set (prior behaviour, byte-exact).
|
||||
* MouseCaptureMode 1 = native-PC: the cursor is free until you click in the
|
||||
* game window; ESC (or focus loss, or opening a menu) frees it again.
|
||||
* Re-entering a stage while still "armed" re-locks automatically so
|
||||
* unpausing / starting a level does not need a click.
|
||||
/* WI-1: Quake-style click-to-lock cursor capture. The cursor is free until
|
||||
* you click in the game window; ESC (or focus loss, or opening a menu) frees
|
||||
* it again. Re-entering a stage while still "armed" re-locks automatically so
|
||||
* unpausing / starting a level does not need a click.
|
||||
* D239/D192: the legacy always-grab mode (former Input.MouseCaptureMode=0)
|
||||
* is removed -- it felt wrong on the file-select menu and its front-end
|
||||
* pointer could not reach the outer grid cells. Click-to-lock is the only
|
||||
* mode now; existing ini files setting the old key are ignored.
|
||||
* Controller input is entirely independent of all of this. */
|
||||
static int mouseCaptureMode = 1; /* WI-1 default: Quake-style click-to-lock + 1:1 menu pointer. 0 = legacy always-grab. */
|
||||
static int captureArmed = 0; /* user has clicked to lock (capture mode) */
|
||||
static int windowFocused = 1;
|
||||
static int mouseAimSpeed = 16; /* aim-mode sensitivity, percent (B3: 50 -> 25 M-29 -> 16; still overshot at 25) */
|
||||
@@ -403,32 +400,10 @@ static int wheelBack = 0;
|
||||
/* Item 1 (D165) — front-end pointer P-controller state. */
|
||||
static int menuPointerMode = 1; /* 0 = legacy velocity, 1 = 1:1 pointer */
|
||||
static int hipfirePitchSpeed = 100; /* D166: hipfire pitch pulse rate, percent */
|
||||
static double menuEstH = 0.0, menuEstV = 0.0; /* estimate of the game cursor (virtual px) */
|
||||
static double menuTgtH = 0.0, menuTgtV = 0.0; /* mouse-driven target (virtual px) */
|
||||
static int menuPrevActive = 0;
|
||||
static double hipPitchPhase = 0.0; /* D166: hipfire pitch pulse phase 0..1 */
|
||||
static int lastMenuMouseX = -1, lastMenuMouseY = -1; /* WI-2: last abs cursor seen in a menu */
|
||||
|
||||
/* Integrate one poll of our cursor estimate with front.c's exact recurrence
|
||||
* (frontUpdateControlStickPosition): the game receives `stick` as an s8, applies
|
||||
* a +/-5 deadzone with a -5 offset, clamps to +/-70, then
|
||||
* cursor += (stick*0.075 +/- 0.5) * delta, and clamps the cursor to [lo, hi]. */
|
||||
static double menuCursorStep(double est, double stick, double lo, double hi)
|
||||
{
|
||||
if (stick > 127.0) stick = 127.0;
|
||||
if (stick < -128.0) stick = -128.0;
|
||||
double x = (double)(int)stick;
|
||||
if (x < -5.0) x += 5.0;
|
||||
else if (x >= 6.0) x -= 5.0;
|
||||
else x = 0.0;
|
||||
if (x >= 71.0) x = 70.0;
|
||||
else if (x < -70.0) x = -70.0;
|
||||
if (x > 0.0) est += (x * 0.075 + 0.5) * MENU_EST_DELTA;
|
||||
else if (x < 0.0) est += (x * 0.075 - 0.5) * MENU_EST_DELTA;
|
||||
if (est > hi) est = hi;
|
||||
else if (est < lo) est = lo;
|
||||
return est;
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------------------ */
|
||||
|
||||
@@ -601,9 +576,9 @@ int inputInit(void)
|
||||
|
||||
inputRebuildBinds(); /* D214: parse [Bind] now that configLoad() has run */
|
||||
|
||||
/* Relative mouse mode for mouse-look. In click-to-lock mode we start
|
||||
* released and wait for a click in the window (video.c -> inputNotifyClick). */
|
||||
mouseGrabbed = mouseEnabled && !mouseCaptureMode;
|
||||
/* Relative mouse mode for mouse-look. Click-to-lock: we start released
|
||||
* and wait for a click in the window (video.c -> inputNotifyClick). */
|
||||
mouseGrabbed = 0;
|
||||
if (mouseEnabled) {
|
||||
if (mouseRawInput) {
|
||||
/* Feed the raw device delta straight through: no OS pointer
|
||||
@@ -812,7 +787,7 @@ unsigned inputComputePad(int idx, signed char *stick_x, signed char *stick_y)
|
||||
* (handled in video.c -> inputNotifyClick). Menus keep their buttons. */
|
||||
/* ...but not while an aim hold has the cursor out for absolute aim:
|
||||
* then the buttons are intentional (RMB is the hold itself, LMB fires). */
|
||||
if (mouseCaptureMode && !mouseGrabbed && !menuMode && !s_absAimSuspend) {
|
||||
if (!mouseGrabbed && !menuMode && !s_absAimSuspend) {
|
||||
mb = 0;
|
||||
}
|
||||
|
||||
@@ -965,7 +940,7 @@ unsigned inputComputePad(int idx, signed char *stick_x, signed char *stick_y)
|
||||
* an absolute mouse position (D165/D169 P-controller) is
|
||||
* unavoidably laggy/floaty and desyncs from the real cursor.
|
||||
*
|
||||
* With click-to-lock (MouseCaptureMode=1) the front end has a
|
||||
* With click-to-lock the front end has a
|
||||
* real free OS cursor, so we know exactly where the pointer is.
|
||||
* Write cursor_h/v_pos DIRECTLY from the absolute mouse position
|
||||
* whenever the mouse moved, and emit a zero stick so the game's
|
||||
@@ -987,7 +962,7 @@ unsigned inputComputePad(int idx, signed char *stick_x, signed char *stick_y)
|
||||
}
|
||||
|
||||
int haveAbs = 0;
|
||||
if (mouseCaptureMode && !mouseGrabbed) {
|
||||
if (!mouseGrabbed) {
|
||||
int mx = 0, my = 0;
|
||||
SDL_GetMouseState(&mx, &my);
|
||||
SDL_Window *w = SDL_GetMouseFocus();
|
||||
@@ -1016,39 +991,6 @@ unsigned inputComputePad(int idx, signed char *stick_x, signed char *stick_y)
|
||||
}
|
||||
}
|
||||
|
||||
if (!haveAbs) {
|
||||
/* Legacy relative path (MouseCaptureMode=0, cursor grabbed):
|
||||
* P-controller onto a mouse-accumulated target (D165/D169).
|
||||
* D180: clamp the estimate to the same live rect as the
|
||||
* target -- D169 widened the target clamp but left the
|
||||
* estimate pinned to the old 320x240 constants, so the
|
||||
* right/bottom of the menu was unreachable and the
|
||||
* controller wound up into never-settling drift. */
|
||||
if (!menuPrevActive) {
|
||||
menuEstH = menuTgtH = cursor_h_pos;
|
||||
menuEstV = menuTgtV = cursor_v_pos;
|
||||
hipPitchPhase = 0.0;
|
||||
}
|
||||
double s = (menuPointerSpeed / 100.0) * MENU_MOUSE_TO_PX;
|
||||
menuTgtH += edx * s;
|
||||
menuTgtV += dyLook * s;
|
||||
if (menuTgtH < loH) menuTgtH = loH;
|
||||
if (menuTgtH > hiH) menuTgtH = hiH;
|
||||
if (menuTgtV < loV) menuTgtV = loV;
|
||||
if (menuTgtV > hiV) menuTgtV = hiV;
|
||||
|
||||
double effH = MENU_P_GAIN * (menuTgtH - menuEstH);
|
||||
double effV = MENU_P_GAIN * (menuTgtV - menuEstV);
|
||||
if (effH > 70.0) effH = 70.0; else if (effH < -70.0) effH = -70.0;
|
||||
if (effV > 70.0) effV = 70.0; else if (effV < -70.0) effV = -70.0;
|
||||
|
||||
menuEstH = menuCursorStep(menuEstH, effH, loH, hiH);
|
||||
menuEstV = menuCursorStep(menuEstV, effV, loV, hiV);
|
||||
|
||||
sx += (int)(effH + (effH >= 0.0 ? 0.5 : -0.5));
|
||||
sy -= (int)(effV + (effV >= 0.0 ? 0.5 : -0.5));
|
||||
}
|
||||
|
||||
if (configGetInputLog()) {
|
||||
sysLogPrintf(LOG_NOTE,
|
||||
"GE_INPUTLOG menuptr abs=%d cursor=(%.1f,%.1f) stick=(%d,%d)",
|
||||
@@ -1239,12 +1181,7 @@ static void applyGrab(int want)
|
||||
* per controller-0 poll (menuMode known there) and from the notify hooks. */
|
||||
static void reconcileGrab(int menuMode)
|
||||
{
|
||||
int want;
|
||||
if (!mouseCaptureMode) {
|
||||
want = windowFocused; /* legacy */
|
||||
} else {
|
||||
want = captureArmed && windowFocused && !menuMode; /* click-to-lock */
|
||||
}
|
||||
int want = captureArmed && windowFocused && !menuMode; /* click-to-lock */
|
||||
if (s_absAimSuspend) {
|
||||
want = 0; /* D194: an aim hold wants the free cursor for absolute aim */
|
||||
}
|
||||
@@ -1265,8 +1202,7 @@ static void applyCursorVisibility(void)
|
||||
SDL_ShowCursor(hide ? SDL_DISABLE : SDL_ENABLE);
|
||||
}
|
||||
|
||||
/* video.c focus events. In legacy mode this directly grabs/releases; in
|
||||
* capture mode it just records focus and lets reconcileGrab() decide. */
|
||||
/* video.c focus events. Records focus and lets reconcileGrab() decide. */
|
||||
void inputSetMouseGrab(int on)
|
||||
{
|
||||
windowFocused = on ? 1 : 0;
|
||||
@@ -1274,21 +1210,20 @@ void inputSetMouseGrab(int on)
|
||||
applyCursorVisibility();
|
||||
}
|
||||
|
||||
/* A mouse click landed in the game window (video.c). In click-to-lock mode
|
||||
* this arms + grabs; otherwise it is ignored (the game sees the click). */
|
||||
/* A mouse click landed in the game window (video.c): arm + grab. */
|
||||
void inputNotifyClick(void)
|
||||
{
|
||||
if (mouseCaptureMode && mouseEnabled && windowFocused) {
|
||||
if (mouseEnabled && windowFocused) {
|
||||
captureArmed = 1;
|
||||
reconcileGrab(0);
|
||||
}
|
||||
}
|
||||
|
||||
/* ESC pressed (video.c). In click-to-lock mode, releases the cursor and
|
||||
* reports 1 so the caller can swallow the key; otherwise reports 0. */
|
||||
/* ESC pressed (video.c): release the cursor and report 1 so the caller can
|
||||
* swallow the key; reports 0 when there is nothing to release. */
|
||||
int inputReleaseCapture(void)
|
||||
{
|
||||
if (mouseCaptureMode && mouseGrabbed) {
|
||||
if (mouseGrabbed) {
|
||||
captureArmed = 0;
|
||||
applyGrab(0);
|
||||
return 1;
|
||||
@@ -1296,8 +1231,6 @@ int inputReleaseCapture(void)
|
||||
return 0;
|
||||
}
|
||||
|
||||
int inputMouseCaptureActive(void) { return mouseCaptureMode && !mouseGrabbed; }
|
||||
|
||||
/* F10 options overlay: while it owns controller 0 the inputComputePad poll
|
||||
* early-returns before reconcileGrab()/applyCursorVisibility(), so whatever
|
||||
* grab state was live when F10 was pressed (relative mode + hidden cursor in a
|
||||
@@ -1397,7 +1330,7 @@ static int aimGepdCompute(double dxPx, double dyLook)
|
||||
|
||||
/* Needs the grabbed-cursor relative deltas (capture mode, locked in a
|
||||
* stage) and a live player. dxPx/dyLook are this poll's dt-scaled px. */
|
||||
if (!aimAbsolute || !mouseCaptureMode || !mouseGrabbed || p == NULL)
|
||||
if (!aimAbsolute || !mouseGrabbed || p == NULL)
|
||||
return 0;
|
||||
|
||||
/* On entry adopt the game's current position (GEPD adopts every
|
||||
@@ -1483,7 +1416,6 @@ static int aimGepdCompute(double dxPx, double dyLook)
|
||||
PD_CONSTRUCTOR static void inputConfigInit(void)
|
||||
{
|
||||
configRegisterInt("Input.MouseEnabled", &mouseEnabled, 0, 1);
|
||||
configRegisterInt("Input.MouseCaptureMode", &mouseCaptureMode, 0, 1);
|
||||
configRegisterInt("Input.MouseAimSpeed", &mouseAimSpeed, 1, 500);
|
||||
configRegisterInt("Input.AimAbsolute", &aimAbsolute, 0, 1); /* D194 */
|
||||
/* D194: renamed Input.GepdSens -> Input.AimModeSens (community name for
|
||||
|
||||
@@ -66,7 +66,6 @@ enum { ROW_TOGGLE, ROW_SLIDER, ROW_ENUM, ROW_MSAA, ROW_RES };
|
||||
|
||||
static const char *const kOnOff[] = { "OFF", "ON", NULL };
|
||||
static const char *const kTexFilter[] = { "NEAREST", "BILINEAR", "3-POINT", NULL };
|
||||
static const char *const kCapture[] = { "ALWAYS GRAB", "CLICK-TO-LOCK", NULL };
|
||||
static const int kMsaaSeq[] = { 1, 2, 4, 8 };
|
||||
|
||||
/* Windowed-mode resolution presets. Filtered at init to those that fit the
|
||||
@@ -124,7 +123,6 @@ static struct Row rows[] = {
|
||||
{ "Input.MouseTurnSpeed", "Mouse turn speed", ROW_SLIDER, 1, NULL, 0, 0, 100, 0,0,0,0,0 },
|
||||
{ "Input.SensLink", "Link aim/turn sens",ROW_TOGGLE, 1, kOnOff, 0, 0, 0, 0,0,0,0,0 },
|
||||
{ "Input.MouseInvertY", "Mouse invert Y", ROW_TOGGLE, 1, kOnOff, 0, 0, 0, 0,0,0,0,0 },
|
||||
{ "Input.MouseCaptureMode", "Mouse capture", ROW_TOGGLE, 1, kCapture, 0, 0, 0, 0,0,0,0,0 },
|
||||
{ "Game.ScreenShakeIntensity","Screen shake", ROW_SLIDER, 0.25, NULL, 0, 0, 3, 0,0,0,0,0 },
|
||||
};
|
||||
#define NUM_ROWS ((int)(sizeof(rows) / sizeof(rows[0])))
|
||||
|
||||
Reference in new issue
Block a user