mirror of
https://github.com/jkdansereau/goldeneye-pc-port.git
synced 2026-10-24 00:02:45 +02:00
James Dansereau
aa6733436a
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