mirror of
https://github.com/jkdansereau/goldeneye-pc-port.git
synced 2026-10-24 00:02:45 +02:00
* D217 (M-90): align texpool arena bases to 8 bytes on PC — fixes solid wrong-colour weapon/model CI tiles Root cause: texAlignIndices pads CI index rows to ABSOLUTE 8-byte boundaries, and model-DL G_LOADTLUT palette offsets are a formula that only matches the real layout when the texpool base is 8-aligned. On N64 the memp bump allocations feeding these pools happened to be 8-multiples; PC pointer bloat (D36/D37-class struct growth) made some STAGE-bank sizes not, so weapon-pool bases land %8==4 (e.g. FACILITY). Every palette in a misaligned pool then sits 4 bytes early inside its allocation while the draw reads the N64 offset: the PP7 grip's count=1 TLUT lands on the next tenant's 8-byte header slot (texnum=26 -> LE s16 -> 0x1A00 = the green), and larger loads read a 2-entry zero pad then the real palette (the M-86 'leading zero pad' tell). BUNKER1 was clean only because its bases happened to be aligned. Fix: texInitPool rounds the arena base up to 8 under #ifdef PORT; end unchanged (pool loses <=7 bytes). No-op on N64 where bases were already aligned. ABI/layout-class edit per AGENTS.md rule 2 narrow exception — no game logic touched. Verified: FACILITY 188/188 decodes %8==0, draw reads pal0=0001 (was 1a00), 0 green pixels in frames 250-450 (pre-fix ~1300); BUNKER1 + DEPOT still clean; full verify.sh sweep 21/21 PASS. Pending: human playtest eyeball of the M-87 weapon matrix (closes defect 1). Defect 2 (CI cache content-hash key, fix/d217-model-texture-palette) remains separate/parked. findings.md: new section H 'D217 - M-90' + D217 row update; GRAPHICS-BACKLOG D217 status. * docs(D217): M-92 - human playtest of PR #47 confirms PP7/PPK/watch fixed; AK47 + NPC-held world-model weapons are a distinct, still-open white-texture residual Claude-Session: https://claude.ai/code/session_016TaKy6AAsVUTfjkhrX6CjG * docs(D217/D228): M-97 human playtest - green FIXED, AK47 white patches split out as D228 Second independent playtest (after M-92) of PR #47 on FACILITY, this time with the branch merged up to date with main. Confirms the same split the M-90 write-up predicted: PP7/PPK grip+hammer, watch face and world-model green are all fixed by the texpool alignment; NPC-held AK47 white missing-texture patches are untouched. White is a different signature from wrong-colour -- a wrong palette binds a real TLUT with wrong contents, white means the texture was never decoded/uploaded at all -- so this is a separate mechanism, not an incomplete fix. Split out as D228 so D217 can close on the green mechanism it actually describes instead of carrying an unrelated open failure mode indefinitely.
20 KiB
20 KiB
GRAPHICS-BACKLOG — known cosmetic / rendering issues
Deferred below level-progression and crash work (user priority, M-11). Minor graphical glitches are acceptable in the current state. Fix these once the game is playable start-to-finish without crashes.
Open
| ID | Symptom | Status / notes |
|---|---|---|
CLOSED — NOT A BUG (M-33, §F D168). The GE_PCDUMP PPM writer never reversed glReadPixels rows, so every capture was upside-down; "mirrored" was a misread of inverted asymmetric content. The game renders correctly on hardware (developer-confirmed). Writer fixed (gfx_opengl.cpp). "Every stage verified non-mirrored" was correct — there was no mirror. |
||
gfx_pc.cpp:1546/1551 PORT block is dead code (guard cms & G_TX_WRAP always false; indexes per-texunit arrays with the vertex index → OOB if reached). |
RESOLVED (M-30, RC3/D167). The in-vertex-loop wrap block was reworked and hoisted to a per-texunit pre-wrap window (gfx_pc.cpp ~1574, now cms-correct and indexed by texunit not vertex), behind the Video.WrapFix knob (default OFF). No longer dead code or OOB. See §F "RC3 · D167". |
|
| D75 | Shrunk (M-33, upright captures after D168). The "overlaps D114 shared mirror" note is withdrawn. Gun-barrel Bond RENDERS correctly (walk + fire, upright) — the "absent" reports were the flipped capture. Nintendo logo IS still broken — renders as two overlapping white ellipsoids shifted left, no wordmark/geometry (a real logoinst model transform/geometry bug, not a flip). Cast roll not re-captured — recheck with GE_PCDUMP="1400-2200:25". findings.md §F "D75 Bug 2 — M-33 UPDATE". |
|
| D76 | 2D disclaimer screen only partially drawn. | §F D76. |
PARTIAL — M-87 user playtest: music plays on the intro, cast/character roll, and main menu — but nowhere else. So audio init/playback works; in-level (per-mission) music is what's actually missing. Re-scope to "no in-level music" and check the level-music trigger path (Audio.c-family level-start music cue) rather than the mixer/playback layer, which is evidently fine. Phase 3 (audio). §F D77. |
||
| CLOSED — NOT A BUG (M-33, §F D168). Same capture-orientation artifact as D114. | ||
| D148 | Level-end cinematics don't play. Dam: hitting the exit trigger should show Bond rappelling down the dam (the bungee jump); instead it cuts straight to the mission-complete report. Broader (M-49 full playthrough): cutscenes are buggy in many places across the game, not just the Dam ending — the user reports frequent cutscene glitches (skipped, wrong camera, misplaced/hovering actors, timing). Treat D148/D160 as the tracking entry for the whole cutscene-reliability problem, not just Dam. | Scripted cutscene / cinematic-camera + Bond rappel anim. Found M-27 during the first full Dam→Facility playthrough. Progression is unaffected — the report and next briefing load fine. The widespread nature (M-49) points at a systemic cause: the propDef/sizepropdef stride desync (D122/D132 family) that misreads CutsceneRecord lookups, and/or D75 anim-model + D173 actor-position bugs showing up wherever a cutscene puts a character on screen, and/or the D155/D156/D193 timing family driving cutscene camera/anim pacing. M-31 (§F D160): static-traced the Dam end ailists (ai_24→ai_17, camera_switch→CutsceneRecord type-46 lookup). Diagnostic GE_D160=1 shipped (c95713f5) — user runs Dam to the exit with it set; the trace pins whether the cutscene AI runs, and whether the propDef-index walk (D122/D132 family) hands camera_switch a bogus cutscene record. Leading hypothesis: propDef sizepropdef stride desync (medium confidence), not D75 anim-model. M-87 user playtest: Bond floating/hover cutscene glitch (D173) still present; new specific instance — Bond spins in circles in some cutscenes, named example the end-of-Cradle Trevelyan-falls cutscene. Likely the same actor-position/anim-root cause manifesting as bad rotation instead of bad height. |
| CLOSED — user-verified fixed (M-87 playtest). No longer reproduces; presumably fixed as a side effect of other front-end/D75-family work since M-49. D75 family. §F D146. | ||
| D170 | Named-NPC "flee" scripted behavior looks wrong on PC: on Silo, Ourumov breaks into a full run the instant he alerts ("Ourumov: Kill him!") rather than the N64 walk/retreat; developer reports Trevelyan behaves the same way on Cradle. M-49 full playthrough: escalated — Cradle (-level_51) is "bugged out completely" from Trevelyan's behavior; the final level's scripted progression breaks. Now folded into / superseded by §F D193 (NPC AI locomotion too slow). |
Observed, not investigated (M-34, from a Silo playtest capture; user bug report — no fix wanted yet). Could be a genuine ailist / chrTick divergence, OR the D155/D156 wall-clock deltaFrames locomotion-anim speed-up (a catch-up spike playing the walk cycle at 2–3×). Verify first: capture the same beat against N64 reference footage before assuming it diverges — Ourumov may be scripted to flee. If it's real, suspect the frametiming clamp (§F D155/D156) or the Cradle-family AI path (§F D123). |
| D171 | Silo missile-shaft: a large translucent grey triangle sweeps across the lower frame while panning down the shaft (~3 s of the capture). Looks like a stray poly / near-plane clip fan, same family as D106 (portal near-plane min>max). | Observed, not investigated (M-34, Silo capture). Cosmetic, intermittent, tied to camera angle in the open vertical shaft. |
| D172 | Bullet-impact / blood particle spray renders magenta or cyan instead of dark red (visible on guards hit at close range on Silo). | M-82: ROOT CAUSE FOUND + FIXED (PR #34). GE_D172 probe on a user Silo firefight: 40/40 particle tris configure tile 1 = RGBA16 fire @ tmem 392 but fast3d samples tile 0 (smoke) for both texunits — gfx_lod_tile_offset() returns 0 unconditionally (D107 blurry-ceiling fix; video.c:225 disables gfx_detail_textures_enabled). G_CC_INTERFERENCE = smoke*smoke → magenta/cyan. Fix: return rdp.tex_lod ? 0 : i — only fold to base tile for real LOD/mip draws. (0xB9 + cycle-type were both false trails, ruled out earlier in M-82.) Owed: in-game eyeball — blood should be dark red. Detail: D172-PARTICLE-COLOR-RESEARCH.md. |
CLOSED — user-verified fixed (M-87 playtest): "main menu text is good now." No longer reproduces. M-36 triage below kept for reference. M-36 triage: the objective lines are BLANK, not wrong. GE_STARTMENU=10 Dam briefing renders the header fine ("OHMSS / Agent: James Bond / Mission 1: Arkangelsk / Part i: Dam / PRIMARY OBJECTIVES:") then just the bullet "a." with no text and no b/c/d. → D143/D151 blank-text family (langGet() → NULL → silent blank), not a propDef walk / difficulty decode. Family B in docs/dev/M-36-TRIAGE.md — find which lang bank the front-end briefing flow fails to load. Re-confirm the exact shape in a real briefing (the GE_STARTMENU boot skips real save state). Close relatives: D151 (watch objective text blank — type-35/23 text slot u16→u32 fix, M-28; interactive re-verify was still pending), D143 (briefing/objective text blank via langGet NULL), D157 (objective difficulty byte offset — could make difficulty-gated objectives appear/disappear wrongly). The pre-start briefing is a different surface from the in-level watch, so D151's fix may not cover it. Next: ask user which level + what exactly shows vs expected; compare against docs/dev/LEVEL-OBJECTIVES.md (regenerated post-D157); if lines are blank → D143/D151 family (langGet NULL guard = silent blank), if wrong objectives listed → propDef type-23 record walk / difficulty decode. |
||
| D175 | In-game stutter / brief hang during normal play — observed opening a door on Runway (mission 3, -level_35) and also on Surface. No backtrace captured (gdb attach missed the window; it self-recovered). |
Observed, not investigated (user QA report). Matches known transient-hang classes rather than looking new: D155 (post-slow-load catch-up spiral — clamped), D156 (anim NaN loop — guarded, prints one-shot stderr diag if it fires), D134 (SP/DP task-done event swallowed — fixed M-22, Runway was an original victim), D147/D152 (audio s_imLock steal = ~2 s hiccup). Door-open specifically = new room first visible → one-off texture-import/frame spike (likely benign). Next: reproduce under tools_pc/debug.ps1 with the box idle; check console for the D156 stderr diag; if it recurs, attach gdb mid-hang and pattern-match bt (import_texture = benign slow frame; model.c:3131 spin = D156; pthread_mutex_lock on s_imLock = D147/D152). |
| D176 | Surface exterior renders wrong (two co-located defects). (a) Sky is solid black — the skybox / sky gradient does not draw at all (reference: warm sunset cloud gradient). (b) The perimeter tree-line backdrop renders as grey TV-static / comb interlacing instead of snow-laden pines — the geometry is present and roughly the right silhouette but every tree texture is scrambled noise. Ground, tunnel and the dish/bunker building draw fine. | Observed, screenshots committed (M-35, user QA; docs/img/bugs/d176-surface-exterior-our-build.png vs -reference.png). Level is the shared Surface exterior — user reached it Dam→Surface on Agent so this is Surface (i) -level_36 (confirm it also affects -level_43). (a) black sky: M-36 partial (findings.md "D176(a)"). Env data is correct (Sky.Clouds=1, CloudRGB=240,120,30, SkyImageId=0); skyRender runs the cloud path and classifies corners correctly (switch case 12), but skyRenderTri/skyRenderFull emit nothing — not even the env->RGB fill shows. Not root-caused: next is probing sub_GAME_7F097388 projected coords, verifying skywaterimages[0] resolves on PC (image_bank.c GIMG offset 0xFB4), and a fast3d sky-tri trace. GE_D176=1 probe shipped. M-37: ROOT-CAUSED — skyRenderTri/skyRenderFull build geometry exclusively as G_RDPHALF_* immediates, which gfx_pc.cpp deliberately no-ops (identical no-op in the PD port); fix = decode the RDPHALF tri-raster stream in fast3d (~1 session, genuine new code). M-42: -level_22 (Statue) confirmed a clean headless repro — bare boot, frame ~360, upper half pure black; use it to verify the decoder. M-47 + read-only consolidation: Path B draft exists (scratchpad/sky.patch, skyPortRenderPoly PORT hook — geometry+texture reach GL, two unit defects open) and the full RDPHALF wire format is now decoded (S15.1 half-packing, 8-component perspective-interpolated vertex vectors); next session is mechanical per docs/dev/D176a-SKY-NOTES.md. -level_36/-43 intro cams face down (not a sky test without GE_INPUTSCRIPT). M-82: PR #18 rebased onto main + Defect-1 fix applied — cloud tile is s_skywaterimages[0] = 64×64 IA8; the patch's tc = S·32 scale is correct (matches GE's width<<5 idiom, glass2.c:678), the bug was (s16) overflow on the ±20k-texel horizon S/T; fix = per-primitive phase-fold to the 64-texel period (sky.c skyPortRenderPoly, #ifdef PORT). Builds clean, no crash (bunker1/statue/surface1 verify PASS). Unverified visually — owed: one -level_22 screenshot (see D176a-SKY-NOTES.md "verification ask"). Defect 2 (horizon-band coverage / straddling tris) still open → adaptive tessellation. (b) tree/rock static: M-36 triage — NOT the D159 family. texSwapAltRowBytes is a full #ifdef PORT no-op (image.c:2199), it cannot cause this. Real cause: port/fast3d/gfx_pc.cpp import_texture_* assume line_size_bytes == full_image_line_size_bytes (SUPPORT_CHECK; rgba16's is commented out "trips ... with a garbage size" :658) → non-PoT / sub-rect tiles get a flat linear read → diagonal row shear = grey static. Family A in docs/dev/M-36-TRIAGE.md. Fix: honour line_size_bytes as the real source pitch. Same defect as D182(2). |
| D217 | 1P weapon viewmodel + character-model CI textures render with a wrong palette on many levels / multiple weapons — PP7 grip + hand render flat green on Facility & Depot, "weird or missing" gun textures elsewhere; Bond's watch face too. Surfaced by D215 (viewmodel now draws). Clean on Bunker1. | Defect ① FIXED (M-90), pending human playtest eyeball — full detail in findings.md §H "D217 — M-90" and §F D217. Root cause: weapon texpool arena bases land %8==4 on PC (memp bump drift from pointer bloat); texAlignIndices absolute 8-byte row padding then shifts every palette 4 bytes early while model-DL G_LOADTLUT reads the N64 offset (grip count=1 load lands on next tenant's header slot → 0x1A00 green; larger loads read a 2-entry zero pad — the M-86 tell). Fix: texInitPool rounds the base up to 8 under #ifdef PORT (no-op on N64); 21/21 sweep PASS. Two defects: ① visible green = misaligned texpool arena (fixed as above). ② CI texture-cache collision (no palette-content key) — proven, fix landed on branch fix/d217-model-texture-palette f6fc0399 (palette FNV-1a hash in the CI cache key), owes a 21-level verify.sh sweep; does not fix ①. |
| D174 | "No blood effect" — user reports no visible blood when shooting guards / into surfaces. | User QA report; likely D120, unverified. Decals: the D120 PointUsage[] converter fix (M-30) was never interactively verified and only takes effect after a full sidecar regen (d43 && d69 && d88 --regen) — check whether the playtest build had regenerated sidecars before concluding the fix failed. Spray: D172 observed the particle spray drawing (wrong color, magenta/cyan) on Silo — if the user sees no spray either, that's new info (different weapon/range, or the D172 decode is worse than "wrong color"). First step: BUNKER1 firefight with regenerated sidecars; if decals still absent, instrument the chr.c:3328 decal walk. |
| D173 | Third-person Bond model (the player-representing figure shown at level start) spawns too high — floats well above the ground "a lot of the time" while the actual player spawn is correct. Same symptom on the Cuba end credits: JB stands ~6 ft in the air above Natalya. | Confirmed still present across the full 21-level playthrough (M-49). Observed, not investigated (user QA report). D75 animated-model family but a position defect, not absence — M-33 confirmed the gun-barrel Bond renders fine upright. Suspects: (a) intro/credits puppet chr spawn position vs the model's base transform; (b) anim root-motion accumulation (modelSetAnimFrame2WithChrStuff, D156 area) offsetting the rendered joints above the body origin; (c) a coord3d/packed-float decode in the intro camera/model setup. "Player spawning is OK" localises it to the render-side model, not g_CurrentPlayer state. |
| D182 | SELECT FILE screen degrades after navigating away and back (main menu → file select, or backing out of file select and re-entering). On the fresh screen the 007 gun-barrel spiral / Bond silhouette renders behind the file boxes; after a round-trip the Bond image stops drawing entirely and the whole background gains the comb / interlacing artifact (horizontal line scramble). File boxes, text and the Copy/Erase icons still draw. | Observed, screenshot committed (M-35, user QA; docs/img/bugs/d182-file-select-backout-20260902.png). Two symptoms, likely linked: (1) background 3D image stops rendering after re-entry → a front-end model/DL whose render_pos / segment binding is only valid on first construction (D149 / D75 constructor_menuXX family — the dossier/wallet models have the same "renders once" behavior). (2) interlacing = M-36 triage: Family A, the import_texture_* line vs full_image_line shear (see D176(b) / docs/dev/M-36-TRIAGE.md) — not the D159 texSwapAltRowBytes path (that is a full PORT no-op). Open question: why only after a round-trip — first import may land line == width, re-import may not, or the tile descriptor is stale on re-entry. Repro: GE_STARTMENU to file-select, back out with ESC/B, re-enter; GE_DTEX on the spiral texture across both visits. Shares defect (2) with D176(b). |
| D197 | Character face/head textures wrap wrong — the face texture repeats around the side of the head "and continues weird" instead of clamping to the front. Seen on Silo (M-49 playtest), intermittent ("sometimes"). Reads as G_TX_CLAMP not honoured for the character-skin tile in fast3d (→ GL_REPEAT, so the face UV region tiles around the skull), or wrong shifts/shiftt / LOD-tile selection on the head texture, or the D167 non-PoT wrap-period issue (head textures are often non-PoT) hitting skinned models. |
Observed, not investigated (M-49, user bug report — needs a capture + which chr/level). Distinct from D176(b)/D182(2) (those are bg wall pitch shear). Related: RC3/D167 (Video.WrapFix, non-PoT wrap period) + the texWriteTileLods shifts=shiftt=lod note in findings §F "D176(b) → 4. candidate 2". First checks: does gfx_pc.cpp map N64 cms/cmt G_TX_CLAMP → GL_CLAMP_TO_EDGE for character DLs; is the head tile getting the base tile vs an LOD tile (D107); try Video.WrapFix=1 on a repro. |
| D195 | Transparency / alpha-blended surfaces render wrong — reported on Control (Severnaya bunker basement — Natalya's console room; heavy on glass partitions and the translucent projected/holographic wall displays). Exact failure mode not yet pinned by the reporter (M-49 playtest): candidates are alpha-blended geometry drawing fully opaque, translucent panels drawing invisible, or draw-order/sort so translucent surfaces occlude what's behind. | Observed, not investigated (M-49, user bug report — needs a GE_PCDUMP capture + which surfaces). fast3d render-mode / combiner path. Same neighborhood as D161 (CI8 tile + G_TT_NONE → garbage), D172 (particle-sprite channel order), D176(b) (texture pitch shear) — but this is a blend/alpha defect, not a texture-decode one. Note D128 already touched Control's specialportalarray (portal struct stride) — check whether the affected surfaces are portal-adjacent. First checks: does gfx_pc.cpp honour G_RM_* XLU render modes + G_AC_THRESHOLD/G_CC alpha for these DLs; is gDPSetRenderMode w1 being parsed (cf. findings §F "zbuf-clear w1 scribble"); is Z-write-vs-blend ordering right for XLU surfaces. Get the reporter to say: opaque-where-should-be-clear, invisible, or wrong edges? |
| 1P weapon viewmodel | RESOLVED (M-83, D215). In-level first-person weapon models drew nothing. Root cause: gunRenderFirstPersonGunModels built its ModelRenderData via *(ModelRenderData*)&D_80035CC0 — a reinterpret across two separately-declared adjacent globals that only lands right on the N64 linker + 4-byte pointers; on x86-64 renderdata.flags read 0, gating every weapon DL node off in modelRenderNodeGundl. All 3 ranked suspects in VIEWMODEL-RESEARCH.md were ruled out first by the GE_DVM=1 probe. Fixed #ifdef PORT (explicit field init). subdraw 1→153 gfx cmds; owed one BUNKER1 eyeball. |
Resolved (for reference)
- D70–D74: intro-logo pixels (Rareware logo renders correctly).
- D103: viewport / native-resolution half-frame.
- D105: room geometry Z-buffer never cleared (
G_CLEAR_DEPTH_EXT). - D106: sky-void through doorways (portal near-plane min>max).
- D107: blurry ceilings/wall-panels (LOD mip tile fabrication).
- D112: skeletal models were "3D lines" (
d43_emit.py put_f32byte order).