Scripted-fire repro (GE_INPUTSCRIPT, 64 Z-pulses) on -level_33 with
GE_D172=1: 40/40 particle multitex tris sample SAMPLED1=tile1 (tmem=392),
the correct RGBA fire tile (pre-fix behaviour was tile0/smoke); zero
BUG/unknown-GBI/D146-abort lines; 0 purple/magenta pixels across 28
captured frames. Row can close on a human by-eye pass (folds into the
D217 PR #47 playtest).
Static analysis found no separate/unfixed code path -- the explosion
DLs use the identical G_CC_INTERFERENCE/G_CC_MODULATEIA2 two-tile
mechanism D172 already fixed in gfx_lod_tile_offset. Not yet runtime-
confirmed (needs a scripted explosion repro on Dam with GE_D172=1).
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
Added a GE_D217TEX env-gated probe (src/game/image.c, texInflateZlib)
logging texnum/numcolours/palette[0..1] straight off the decode
bitstream -- the most direct check of whether the SAME texture number
decodes to the SAME bytes across levels.
Result: texnum=1608 (the PP7 grip, confirmed by its pal0=0001 matching
the previously-documented BUNKER1-correct value) decodes IDENTICALLY on
both BUNKER1 and FACILITY. This disproves the 'different ROM bytes per
level' theory and confirms the bug is strictly downstream of a provably
correct decode.
Then built and tested the parked fix/d217-model-texture-palette
(f6fc0399, the CI-texture-cache content-hash fix, defect (2)) directly
against the FACILITY repro -- still renders green. That fix does not
close this row; defect (1) and (2) are confirmed separate bugs.
New leading theory: a stale/dangling tex->data pointer into the
texpool arena, re-resolved once and not re-checked at draw time, so a
later texture decode reusing the same arena address on a texture-heavy
level silently overwrites the grip's palette bytes. Documented as the
concrete next probe for whoever picks this up.
Probe left in tree, env-gated (GE_D217TEX), inert by default.
tools_pc/verify.sh bunker1: PASS, no regression.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
Local-Qwen triage proposed hardcoding pitch=1 in gfx_dp_load_tlut
(port/fast3d/gfx_pc.cpp), on the theory that N64 LOADTLUT addressing
never strides by the SetTextureImage width. Verified by hand before
applying it, and refuted:
- gDPSetTextureImage/gSetImage (include/PR/gbi.h) pack width-1 into the
raw command field, and texWriteLoadToTmemAddr always passes width=1,
so pitch = (1-1)+1 = 1 ALREADY for every model-DL TLUT load. The
proposed patch is a no-op for this call site.
- Continuing the derivation confirms base = tex->data + len (the
documented pixel-data-then-palette layout from texInflateZlib) for
every call, regardless of the uls/ult 10-bit-field split -- the
addressing math is correct by inspection.
- tex->unk0a = numcolours - 1 exactly explains gfx_dp_load_tlut's
count = unk0a+1 term, matching the M-85 GE_D217Z count observations
precisely -- the grip tile's count=1 is a genuine 1-color palette,
not a truncated load.
New leads (neither probed this session): (a) does g_Textures[texturenum]
/_imagesSegmentRomStart resolve to identical ROM bytes across levels for
this weapon (a different image-table path than the already-ruled-out
per-model TextureID/d43_emit.py/Globalimagetable/D68 path), or (b) does
the shared texpool arena (image.c texLoad, two-ended leftpos/rightpos
allocator) serve a stale/aliased tex->data pointer for what should be a
fresh per-level decode.
Docs-only. No code changes -- the proposed patch was not applied.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
Root cause: src/game/mp_music.c's sub_GAME_7F0C0BF0() is a one-line wrapper
around get_mTrack2Vol() with no return statement. On N64/IDO the value
happened to already sit in $v0; at the PC release build's -O2 the return
register is genuinely undefined (docs/porting-notes.md D6 class, same as
D187). Every in-level music trigger goes through set_missionstate()'s
MISSION_STATE_1/4 cases (the only path that starts a level's background
track), which feeds this garbage/zero value straight into
musicTrack1ApplySeqpVol()/musicTrack3ApplySeqpVol() right before
musicTrack1Play()/musicTrack3Play() — silencing the whole track for its
entire duration while note-on processing continues normally. Front-end/menu
music bypasses set_missionstate() entirely (front.c calls musicTrack1Play()
directly), which is why it was never affected.
Fix: return the tail call under #ifdef AVOID_UB, #else keeps the N64 body
verbatim. One line, no game-logic change.
Diagnostic: added a temporary, cheap (~1/s, gated on GE_AUDIOTRACE)
[AUDIOLVL] peak/RMS probe of the exact buffer audioSetNextBuffer() hands to
SDL (port/src/audio.c), interleaved into the same audiotrace.log as the
existing csplayer.c [MUSICNOTE] probe via the shared geTracePrintf lock.
Before the fix: 173 [MUSICNOTE] events over a 28s BUNKER1 capture, but every
single [AUDIOLVL] reading (29 samples spanning the full run) read
peak=0 rms=0.0. After the fix: same note count, every [AUDIOLVL] reading
sustained non-zero (peak ~2700-10300, rms ~800-2900). tools_pc/verify.sh
bunker1: PASS, no visual regression.
Docs: docs/dev/findings.md D77 updated from stale "nothing reaches PC
speakers" framing to the actual root cause + verification; new D6 instance
logged in docs/porting-notes.md.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
Dispatched to root-cause + fix D217 defect (1) (wrong palette bytes on
model-DL CI textures) confined to tools_pc/d43_*.py, working theory: a
4-byte/2-entry model-TLUT source-pointer offset in the sidecar.
Investigation refutes that theory: traced the full texture reference
chain (ModelFileTextures TextureID -> Globalimagetable -> runtime
texInflateZlib/NonZlib decode -> texWriteLoadToTmemAddr -> fast3d
gfx_dp_load_tlut) and confirmed tools_pc/d43_emit.py never touches
texture or palette content for model files - it only converts
geometry/node/GDL structure and passes TextureID through unchanged.
Reproduced the exact reported bytes with the existing GE_TEXDUMP env
probe (no code changes): BUNKER1 pal[0]=0001 (black, correct) vs
FACILITY pal[0]=1a00 (green, matches the originally reported defect)
for the same tile=1x1 CI4 grip texture.
Narrowed the likely real mechanism to port/fast3d/gfx_pc.cpp
(gfx_dp_load_tlut palette-address pitch math) interacting with
src/game/tex.c (texWriteLoadToTmemAddr's literal width=1
SetTextureImage) - both out of this dispatch's file scope, so no fix
applied per the brief's own instruction to stop and write up rather
than edit out-of-scope code.
No tools_pc/*.py files modified. docs-only commit.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
User pushed back asking whether the two PD-survey divergence notes were
architecturally sound, not just factually accurate. On review, the
SCREEN_RATIO_16_9 note overstated the plan: it's a live code path but an
old anamorphic-stretch toggle, not true wide-FOV rendering, and this
doc's own pre-existing Open Questions section already leans toward a
separate new Video.Aspect config as Option B's real trigger, leaving the
legacy flag dormant - the same separation-of-concerns choice PD itself
made, not the opposite. Not yet decided (Phase 1). Overscan note (full
frame, no crop) reviewed and confirmed sound as-is - standard modern-
remaster convention, matches Nightdive's own approach.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
Reviewed docs/dev/notes/PD-LEGACY-SURVEY.md (local Qwen agent's read-only
survey of the PD PC port for N64-legacy concepts worth modernizing/
noting) and folded its 8 candidates in:
- D224 (rumble): the stated fix is NOT sufficient alone - two upstream
blockers (CONT_CARD_ON never set; osPfsInit returns PFS_ERR_NOPACK
instead of PFS_ERR_DEVICE) sit before osMotorInit is ever reached.
Both must land alongside the SDL_GameControllerRumble wiring.
- WIDESCREEN-FOV-PLAN: recorded two deliberate GE-vs-PD divergences so
they're never mistaken for gaps - full-frame render (no PD-style
overscan crop) and keeping the SCREEN_RATIO_16_9 path GE already ships
(PD deleted its equivalent) as the widescreen mechanism.
- QOL-INVENTORY per-pad tuning row: PD's incremental hot-plug with
remembered seat is the natural implementation shape, sidesteps GE's
boot-latch controller-mask merge.
- D223 note: PD's per-player PC-controls-mode (save-compat shim) filed
for later, only relevant if P2+ keyboard input is ever a real ask.
- UNLOCKED-FPS-PLAN: PD's TickRateDivisor/ExtraSleep noted as a fallback
lever only if this plan stalls and GE stays fixed-tick.
Candidates 6/7 (MP-setup persistence, PD's PC-only gameplay options)
correctly judged net-new / rule-#2-cost-too-high by the survey - no
action, not re-noted elsewhere.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
User independently confirms D194 part (a) and suggests the fix: aim
sensitivity should scale off the same base per-pixel sensitivity as
normal hipfire-turn mouse movement, not its own disconnected AIM_GAIN/
AimBand floor+clamp curve. Noted this is orthogonal to the SOLITAIRE
scheme change (aim mode is a separate insightaimmode-gated codepath,
untouched by natural-pitch/turn) - needs its own fix either way.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
User correction (they were right): the digital-C-pitch-vs-analog-yaw
asymmetry only applies to the 1.1 HONEY scheme the port currently
forces. User recalled that 1.2 SOLITAIRE uses C-buttons for movement
(fwd/back/strafe) and gives the analog stick full continuous pitch+yaw
('natural pitch/turn') - verified in code (bondview2.c:5195-5253 digital
step movement; :5950/6008 canNaturalPitch/Turn drive
analogPitch//70.0f/analogTurn/70.0f directly, gated only by
!insightaimmode, no threshold/clamp; :4881-4882 these default to the
primary stick's raw X/Y for every 1.x scheme).
This is architecturally identical to modern FPS mouselook. Recommended
fix: force controldef=SOLITAIRE instead of HONEY, WASD -> digital step
buttons, mouse X/Y -> stick X/Y directly and continuously. Resolves the
vertical/horizontal asymmetry with zero digital-pulse emulation (D166's
hack becomes largely moot) and likely much of 'feels unresponsive' too.
Bonus: SOLITAIRE keeps the same shootButtons/invButtons roles as the
current default (not grouped with KISSY/GOODNIGHT's different button
roles), so D223's wheel-cycle plan needs no changes if SOLITAIRE is the
target. GOODNIGHT also gets natural pitch/turn but would need D223 rederived.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
Sky isn't just solid black - where it renders, it scrolls too fast and
repeats too visibly (likely the M-82 phase-fold's 64-texel wrap period).
Cradle (and others) still black specifically at higher FovScale - a
third instance of the 'wide FOV exposes an edge nothing was built past'
family alongside D218 (fog/draw-distance) and D222 (culling); ties to
D176(a)'s already-logged horizon-band coverage/tessellation gap.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
User ask: adjustable HUD scale for the ammo counter, bottom-left pickup/
item status text, and top-of-screen dialogue. All three route through
textRenderOutlined() (textrelated.c:688, doc comment confirms ammo
counter + bottom-left HUD messages), called from exactly two in-game
sites in bondview2.c (:10005 ammo/pickup, :10163/10165 dialogue) -
distinct from the many other callers in front.c/options.c/mpmenu.c
(menu/UI text), which must NOT be scaled by this feature (own layout,
D211 already established HUD anchors stay put). Underlying mechanism:
plain RDP gSPTextureRectangle at native glyph size, dsdx/dsdy=0x400
(1:1 texel:pixel), no scale factor in the chain. Two implementation
directions logged (surgical wrapper at the 2-3 call sites vs. a scale
param threaded through the shared function). No PD precedent. Not
designed or implemented - research only.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
User ask: a debug toggle that always enables all level access and all
cheats, for easier testing. Root-caused a single choke point:
fileGetIsCheatUnlocked() (file2.c:391) is a pure, side-effect-free
save-bitfield read that BOTH the mission-select lock (file.c:59) and the
cheat-menu availability check (frontCheckIfCheatIsUnlocked, front.c:1009)
route through. Short-circuiting it to always-true under an env flag
unlocks both surfaces in one change. Bonus: exposes leftover Rare dev
cheats otherwise unreachable (CHEAT_LINEMODE wireframe - useful for
D222-style culling bugs, CHEAT_BONDPHASE, CHEAT_DEBUG_POS/UNK5). Plan:
#ifdef PORT env-gated (GE_DEBUG_UNLOCKALL), default off = zero behavior
change, no save-data mutation. Not implemented yet.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
Survey of the PD PC port for other N64-legacy things worth dropping/
modernizing (per user ask, following D223's control-preset finding).
D224: GE genuinely has a rumble subsystem (motor.c, joy.c) but the
port's osMotorInit/Start/Stop are hard stubs returning -1 / NOPACK
unconditionally - every rumble event (recoil, explosions) computes and
calls into a dead path. PD's PC port wires the equivalent straight
through to SDL_GameControllerRumble via inputRumbleSupported/inputRumble
+ a per-pad RumbleScale config + options-menu slider - same 'pretend the
N64 accessory is there' pattern this port already uses for osMemSize/
Expansion Pak, just applied to a real capability instead of faked.
Straightforward port-only fix, no game-logic touch.
Also checked and found NOT applicable here: PD's Controller Pak
formatting UI has no GE equivalent (front.c has no PFS/pak menu code),
so there's no dead UI to hide there.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
User asked what the PD PC port did about N64 controller presets for
mouse/keyboard. Checked: PD doesn't route through the N64 controller-
config enum at all - it has its own logical CK_* control-key layer fully
decoupled from it, and treats mouse-wheel-up/-down as two independent
bindable virtual keys (not a single 'wheel = cycle' event). PD's
controldef is hardcoded, not left to the in-game control-style picker.
This GE port already has the equivalent layer: D214's Input.Bind system.
Recommendation logged: add IA_WEAPON_NEXT/IA_WEAPON_PREV bindable
actions that synthesize the invButtons/shootButtons combo, default-bound
to wheel up/down and open for a future gamepad-bumper default; force a
single fixed controldef so the synthesis target is stable. Matches the
user's broader direction (N64 presets aren't meaningful for mouse/kb;
modern Xbox/PS support should be first-class, not routed through N64
presets). Not implemented - design note only.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
User confirms the glitched-color/missing-texture symptom also shows on
NPC-held weapon models (other characters' guns in third person), not
just Bond's 1P viewmodel / 3P world model. Points at the shared
weapon-model-DL/TLUT loading path in general rather than anything
Bond-model-specific.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
QoL ask: wheel up = next weapon, wheel down = previous, instead of both
directions cycling forward. Root-caused: GE already computes separate
weaponForwardOffset/weaponBackOffset signals from
invButtons(A)+shootButtons(Z) held/edge combos (bondview2.c:5338-5347,
the N64 'hold A tap Z' backward-cycle trick); triggerOn is suppressed
while invButtons is held so this never accidentally fires. Port's
inputPostWheel() discards wheel direction and only ever synthesizes the
forward (bare A pulse) case. Fix is port-only (input.c), synthesize the
A-held+G-edge combo for wheel-down instead - no game-logic change.
Open question: which N64 controldef preset is actually active in port
saves, since invButtons/shootButtons differ per preset.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
Split out of D211's 'cosmetic edge-cull-early' caveat - user confirms
this is a real functional bug, not cosmetic: NPCs and some world objects
stop rendering near screen edges at high FovScale. Root cause: frustum
cull / visibility math still runs at nominal unscaled fovy while the
render projection is portFovScale-widened. Fix direction + a real risk
flagged: some of these cull call sites may double as AI
awareness/visibility checks, not just render culling - must audit before
changing so portFovScale never leaks into NPC behavior (non-negotiable
#2, game logic unmodified).
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
D211/WIDESCREEN-FOV-PLAN: user wants Video.FovScale exposed as a real
horizontal-or-vertical degree value instead of the current
percent-of-original-vertical-FOV scale. Not critical, backlogged. Noted
the cleaner path (relabel as degrees, drop the percent indirection) vs
keeping percent internally and just displaying the computed degrees.
D218: user confirms the high-FOV draw-distance/fog artifact still
occurs, and now wants Video.DrawDistance implemented (previously
declined) plus broadened to draw-distance/LOD in general, not just the
fog-boundary case this row root-caused. Open question logged: does GE
have a separate object/geometry LOD-swap distance mechanism worth
exposing, or is Visibility.FarFog the whole story.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
User wants overall mouse feel closer to Quake Remaster / the Perfect Dark
PC port (raw, direct, responsive) while explicitly preserving GE's
aim-mode vs hipfire split (the reason D118/D194 exist). Reframes the fix
order: normalize by a fixed reference dt first (D194 part b, the
frame-rate coupling - likely the dominant cause of 'feels
unresponsive'), then re-derive the aim-mode curve, and evaluate raw
PD/Quake-style hipfire mouse-look as a real option outside aim mode
rather than assuming N64 stick-emulation is mandatory everywhere.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
D178 (briefing objectives blank) and D149 (front-end 3D models garbled) -
user-verified fixed, closed.
D182 (file-select round-trip degradation) - still broken, confirmed.
D77 (no music) - rescoped: music plays on intro/cast-roll/main menu, only
missing in-level. Points at the level-start music cue, not the
mixer/playback layer.
D221 (new): SELECT FILE mouse hit-box vertically offset from the visible
box (click below a file to select it) under the shipped default
MouseCaptureMode=1 - distinct from D192's clamp-range bug under legacy
mode 0, likely same front-end grid-coordinate family.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
D176: skybox still glitchy broadly (not just Surface); Cradle named as
still showing solid black where sky/backdrop should be. Confirms (a)
never landed a verified fix.
D173: Bond hover/float cutscene glitch still present.
D148/D160: new specific instance - Bond spins in circles in some
cutscenes (end-of-Cradle Trevelyan-falls cutscene named) - likely same
actor-position/anim-root cause as D173, manifesting as bad rotation.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
D211: user-verified good at big FovScale.
D217: playtest matrix across weapons/levels (PPK/AK47/M16, Dam/Facility/
Jungle) - green, blue, white (missing), orange, all consistent with the
per-weapon-material upstream theory, not one fixed offset. Watch still
green.
D219 (new): PPK explosions render purple on Dam - likely D172 particle-
color family, different DL.
D220 (new): 1P muzzle flash shifts upward at higher FovScale (Jungle
M16) - likely same unscaled-viewmodel-fovy root as D211's residual
caveat.
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
D217: two defects found. (1) The visible green grip/hand is upstream of
fast3d — the grip's count=1 model G_LOADTLUT is fed different source bytes
per level (Facility 1a 00 -> 0x1A00 green; Bunker 00 01 -> black); every
larger model TLUT carries a 2-entry leading zero pad, so the port's
model-TLUT source pointer is likely 4 bytes low (or a d43_emit.py blob
offset). fast3d byteswap is correct (proven by Bunker). (2) A real CI
texture-cache collision (no palette-content key) — fix landed on branch
fix/d217-model-texture-palette f6fc0399 (palette FNV-1a hash in the CI
key); owes a 21-level sweep; does not fix (1). porting-notes + graphics-
backlog updated.
D211: aim-zoom compose verified correct by construction (single post-lerp
multiply at the fr.c chokepoint; zoom ratio preserved). Only a low-risk
cosmetic eyeball remains (viewmodel/frustum-cull use unscaled fovy).
Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG
GE_D217Z experiment (zero rdp.palette[count..255] after each partial
load) did NOT change the green grip -> bad texels index within [0..count),
so the wrong palette is *bound* to the grip tile, not tail overflow.
Best remaining theory: TextureCacheKey collision / missing CI-cache
invalidation on palette change (key has no palette-content hash). Facility
renders green-uniformed guards right before the viewmodel -> a stale
cache HIT / palette_addrs collision makes the grip decode against the
guard-fatigue palette. Next probes + the all-levels regression
requirement noted in the finding.
Claude-Session: https://claude.ai/code/session_01U7gyYC3pcatXHhD1kPCgsR
User confirms D217 is widespread (many levels, multiple weapons), not
Facility-specific. GE_D217 temp probe (reverted) shows GE weapon/character
model DLs issue partial-count G_LOADTLUT commands (count 1/28/125/172/193/
...); count=125 writes rdp.palette[0..124] and leaves [125..255] holding
the previous TLUT's entries, which differ per level. Weapon TLUT sequence
is identical BUNKER1 vs FACILITY (same PP7) + tiles import palidx=0
cache=HIT, so the delta is purely which stale upper-palette entry a weapon
CI8 texel lands in when it indexes >= its palette count. Root cause open:
CI8 decode reading past the base image (RC2/D183) vs GE relying on N64
TMEM-TLUT leftover semantics. Concrete next probes + a zero-the-tail
experiment noted in the finding. Wants a dedicated debug session.
Claude-Session: https://claude.ai/code/session_01U7gyYC3pcatXHhD1kPCgsR
BUNKER1 is clean in any config; -level_34 FACILITY reproduces at ~frame
300 (just after the vent-drop cutscene). PP7 grip = solid green block,
green ring at the barrel joint, hand has a green cast; slide/barrel upper
is correct black. GE_TEXI confirms the weapon CI tiles import with a
loaded TLUT (fmt=2 palfmt=0x8000 palidx=0) -> gDPLoadTLUT does reach
gfx_pc.cpp for model DLs. Green-tinted hand => wrong TLUT bound, not
corrupt index data. Working theory: FACILITY pre-level cutscene leaves
fast3d palette/tile state (or a TextureCacheKey collision on
rdp.palette_addrs[] at gfx_pc.cpp:990) that the cutsceneless BUNKER1
never hits. Next steps + suggested subagent scope in the finding.
Claude-Session: https://claude.ai/code/session_01U7gyYC3pcatXHhD1kPCgsR
D217: did not reproduce headlessly on main @ 3fa1ba53. GE_DTEX/GE_TEXI/
GE_TEXDUMP on -level_09 across FovScale 100/120/150, TextureFilter 1&2,
FixMipTextures 1&0, Anisotropy 4&16 -> PP7 + hand + guard models all
render clean. gDPLoadTLUT DOES reach gfx_pc.cpp for model DLs (weapon CI
tiles import palfmt=0x8000 with non-stale palettes) -> the stale-rdp.palette
hypothesis is disproven for the BUNKER1 start pose. Row updated with the
remaining leads; blocked on a user screenshot of the actual defect.
D211: headless FovScale 100-vs-120 diff confirms HUD-static (ammo counter
screen position identical, no 4:3 stretch, viewmodel composes). aim-zoom
eyeball still owed.
Claude-Session: https://claude.ai/code/session_01U7gyYC3pcatXHhD1kPCgsR
D211 didn't affect the in-level view (user test): the fast3d
gfx_apply_fov_scale hook only recognised *pure* perspective matrix loads,
but GE draws the world through g_CurrentPlayer->field_10E0 -- a
projection x view matrix pre-combined on the CPU (bondview2.c:8224) --
which failed the guard. Only the pause/watch model + sky FOV changed.
Fix: scale fovy game-side at the guPerspectiveF chokepoint
(src/fr.c, #ifdef PORT, frFovY *= portFovScale, clamp 160deg), which
lands before the CPU combine. Removed the fast3d hook + gfx_api.h decl;
port/src/video.c now sets f32 portFovScale. Gated to
lvlGetCurrentStageToLoad() != LEVELID_TITLE so the front end (which
renders through the same path) keeps its authored FOV.
User-verified: menu unaffected, in-level view widens (Dam tunnel).
Caveat: currentPlayerSetCameraScale keeps nominal FOV for frustum-cull
/ screen<->world math (edge geometry culls slightly early at high scale).
Adds src/fr.c as a #ifdef PORT game-code touch (D181 policy class).
Docs (this test pass):
- D214: config.c sections by the last dot, so binds live in [Input.Bind]
not [Bind]. Doc-only fix (finding, index, QOL-INVENTORY); code unchanged.
- D217 (OPEN): viewmodel + 3rd-person Bond model textures render garbled
-- stale-palette CI-texture bug (D161 family), surfaced by D215.
- D218 (LOGGED, parked): wide FOV exposes the per-level FarFog
draw-distance boundary; Video.DrawDistance fix proposed.
New s32 portSkipIntro (port/src/video.c, configRegisterInt Game.SkipIntro),
read once in src/game/lv.c at LEVELID_TITLE stage load, in the else branch of
the existing GE_STARTMENU #ifdef PORT block. When set it performs the same
state change every intro stage's own !is_first_time_on_main_menu branch does
(front.c): is_first_time_on_main_menu=FALSE; prev_keypresses=TRUE;
maybe_is_in_menu=TRUE; menu_update=MENU_FILE_SELECT. So it reuses the game's
own post-intro route rather than inventing one; the legal screen + logo
attract loop is skipped. GE_STARTMENU still wins when both are set.
Default 0 => unchanged. Verified headless: default boot frame 90 = the
TWYCROSS classification screen; SkipIntro=1 frame 90 = the SELECT FILE menu
(folders/photos/cursor render, no crash across repeated boots). Screenshots
eyeballed.
findings.md D216 + index; QOL-INVENTORY row marked done.
gunRenderFirstPersonGunModels built its ModelRenderData with
renderdata = *(ModelRenderData *)&D_80035CC0;
a reinterpret that reads the lone `u32 D_80035CC0 = 0` and continues into the
next declared global `u32 D_80035CC4[] = {1, 3, 0, ...}` (gun.c). On N64 that
yields { basemtx=0, zbufferenabled=1, flags=3, rest=0 } because the linker
lays the two globals out contiguously in declaration order and pointers are
4 bytes. On x86-64 it breaks twice: ModelRenderData's pointer members widen
4->8 B (so `flags` is no longer at struct offset 8) and C guarantees nothing
about the two globals' placement. Measured (GE_DVM=1, BUNKER1): flags == 0,
which gates every weapon-model DL node off in modelRenderNodeGundl
((renderdata->flags & 1)) -> subdraw emits 1 gfx command instead of ~150 ->
no gun visible while playing.
All three VIEWMODEL-RESEARCH.md ranked suspects were ruled out first by the
same probe: field_87F==1, RootNode valid, numRecords 22 < pool 192, node walk
visits 24+ valid DL/SWITCH/BSP nodes.
Fix: #ifdef PORT -> set the fields explicitly (zbufferenabled=TRUE; flags=3);
N64 line verbatim under #else. ABI/layout only (D3x class), no logic change.
Verified (headless): GE_DVM=1 post-fix shows flags=0x3 and the weapon subdraw
now emits 153 gfx commands (was 1); bunker1 framediff worst_cell 12.2 -> 28.5
(gun renders in-frame); Dam/Facility/Bunker1/Archives/Cradle/Aztec sweep
crash-free. Owed: one BUNKER1 eyeball; the bunker1 golden needs re-baselining.
GE_DVM gate+render probes left in, env-gated (cf. GE_D193*).
findings.md D215 + index; GRAPHICS-BACKLOG + VIEWMODEL-RESEARCH marked resolved.
port/src/input.c: 12 gameplay actions (Forward/Back/StrafeLeft/StrafeRight/
TurnLeft/TurnRight/Fire/Aim/Action/Cancel/LeanLeft/Start), each bound to a
comma-separated list of up to 4 SDL scancode names via Input.Bind.* keys.
inputRebuildBinds() parses them in inputInit() after configLoad();
SDL_GetScancodeFromName resolves names, unknowns warn + skip. The hardcoded
keyDown(ks, SDL_SCANCODE_*) block in inputComputePad is replaced with
actHeld(ks, IA_*). Mouse buttons (fire/aim) stay hardwired.
File-driven, no UI -- matches the PD port. A fresh ge007.ini gets the full
[Bind] block with defaults visible.
Defaults reproduce the previous FPS layout exactly: all 20 default key names
round-trip to the identical SDL_Scancode the old code used (0 mismatches in a
SDL_GetScancodeFromName test). Build clean; verify.sh dam/facility/bunker1
PASS crash-free.
findings.md D214 + index; QOL-INVENTORY row marked done.
Three port-only knobs, each defaulting to byte-identical behaviour:
- Video.FovScale (D211): multiplicative half-angle scale on every perspective
projection matrix as it is loaded (gfx_apply_fov_scale, gfx_pc.cpp). Columns
0+1 scaled together so H/V FOV widen uniformly and aspect is preserved; ortho
(HUD/menu) matrices untouched. Composes with the game's per-frame aim-zoom
rewrites for free. Percent of vertical FOV, 50-150, default 100 => guarded
early-return (zero FP ops, golden dumps byte-identical). WIDESCREEN-FOV-PLAN
Phase 4, landed standalone.
- Video.Anisotropy (D212): expose fast3d's already-implemented GL anisotropy
hook as config (1-16). New gfx_set_anisotropy_level() extern-C wrapper clamps
to the GL max. Default 4 = the value fast3d already hardcoded => no delta.
- Video.DisplayFPS (D213): PD-parity top-right FPS readout, sampled once per
emitted frame (optionsoverlay.c fpsTick). Config-only; default 0 => emit
still returns NULL with the panel closed.
F10 overlay gains 'Anisotropic' and 'FOV scale %' rows (DisplayFPS is file-only
- the panel is at its 13-row layout limit, matching PD).
Build clean (ntsc-final); bunker1 framediff worst_cell 12.219 vs 12.221
baseline = render noise, no-op confirmed. Interactive eyeballs owed (see
docs/HANDOFF.md M-83).
findings.md: D211-D213 rows + index regen. WIDESCREEN-FOV-PLAN Phase 4 and
QOL-INVENTORY rows marked done.
The old 'cyc2 combine at cycletype=1CYC' probe over-fired on trivial
passthrough cyc2 terms. Replace with one that fires only when a 2-cycle
triangle actually consumes TEXEL1 (the G_CC_INTERFERENCE particle case) and
dumps both texunits' tile/tmem/fmt/siz. One Silo capture then shows whether
TEXEL1 resolves to the fire tile (tmem 392, RGBA16) or something wrong.
Build clean; bunker1 verify PASS.
Real particle records (assets/oddtextures.c globalDL_0x078..) DO set
gsDPSetCycleType(G_CYC_2CYCLE); GE_D172=1 probe confirms fast3d applies it
(particle combine fc26a004 logged at cycletype=2CYC). Both the 0xB9-abort
and the cycle-type hypotheses are now dead. Bug is the G_CC_INTERFERENCE
two-tile combine / TEXEL1 path (IA8 smoke x RGBA16 fire @ tmem 0x188).
Probes (#ifdef PORT, GE_D172=1, inert otherwise):
- gfx_pc.cpp G_SETCOMBINE: distinct combine + active cycletype
- gfx_pc.cpp gfx_sp_tri1: tris with cyc2 combine drawn at cycletype!=2CYC
Needs a display capture to go further (headless can't see particle colour).
0xB9 == G_SETOTHERMODE_L in this non-F3DEX2 build (G_IMMFIRST-6); fast3d
handles it as gsDPSetRenderMode. -level_09 sustained-fire run: zero D146
aborts, zero warnings. Re-scoped to the 2-cycle/cycletype hypothesis
(records never set G_MDSFT_CYCLETYPE -> use_2cyc==0 on PC -> TEXEL1
garbage -> magenta/cyan).
Cloud tile is s_skywaterimages[0] = 64x64 IA8, G_TX_WRAP -> it tiles.
GE's screen-space textured-quad idiom is tc = width<<5 (glass2.c:678), so
skyPortRenderPoly's *32.0f scale was correct; the bug was (s16) overflow on
the +/-20k-texel horizon S/T (unk20/unk24 are texel coords, not fractions).
Fix: fold every vertex of one primitive by the same multiple of the 64-texel
tile period before scaling. Inter-vertex deltas (hence the interpolated
cloud texture) are preserved; magnitudes stay in s16 range. Exact for any
triangle whose S/T span is < ~1000 texels -- everything except tris
straddling the horizon line, which are Defect 2 (adaptive tessellation).
sky.c #ifdef PORT only; N64 path unchanged. Builds clean; bunker1 + statue
verify PASS, no crash. UNVERIFIED VISUALLY -- owed: one -level_22 screenshot
(D176a-SKY-NOTES.md 'Verification ask').
Also: rebased onto main (porting-notes.md conflict resolved).
skyRenderTri/skyRenderFull emit the sky as a verbatim N64 RDP triangle
command chopped into G_RDPHALF_* immediates, which fast3d deliberately
no-ops -> Surface/Statue/Streets skies render solid black.
Behind #ifdef PORT, substitute a screen-space gSPVertex + gSP1Triangle/
gSP2Triangles emit built from the already-projected SkyRelated38 verts
(new helper skyPortRenderPoly, ortho matrices via dynAllocate*). N64 path
unchanged under #else. Pure RSP-idiom substitution, no behavioural change.
Links 243/243. Render check owed on a display: -level_22 frame ~360.
findings.md D176(a) M-46; porting-notes.mdD.
James Dansereau