Files
NX2navi/runtime
chrg6 4956ef8365 Let a finalized slot sample its own texture's image while that still holds the texture, not the stand-in.
The game finalizes texture objects on its own thread ahead of the replay, which still draws the frame the game recorded
before that; on the console the memory still holds the texels those draws read. Kakariko moves about 30 of its
textures to new addresses every four or five frames, and each move finalized the old descriptors. The replay's draws
of the frame before then met finalized CPU-written slots, and the stale rule gave them the stand-in even when their
own entry was still there with its content. The village's haze dropped out of a frame a few times a minute, and the
haze sprites that met a stand-in left hard-edged clear patches. A play session in Kakariko logged up to 4,805 stand-in
lookups in 60 frames, 1,826 in the 60 frames around one haze dropout, and 612 in the 60 frames after a run of
patched frames.

Such a slot now resolves to its own entry while that entry was uploaded or drawn by the GPU, and was neither superseded
by another descriptor at its address nor overwritten. The lookup samples the image as it is: it neither takes the
entry back nor reads its storage, so freed storage is still never read (the access violation the stale rule was made
for). NX2NAVI_TEX_STALE_KEPT=0 gives the stand-in again. The perf log's finalize line counts these lookups.

In a replay of a recorded Kakariko walk, most 60-frame windows went from stand-ins to the kept image (up to 328 a
window, stand-ins 0). In play, stand-ins remain in short bursts where the entry was already gone (up to about 2,000 in
60 frames, against the kept image in most windows). The tester still sees flicker that the 640x360 frame recorder
does not catch; that is not settled by this.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-12 05:42:43 -05:00
..
2026-11-07 05:04:38 -05:00
2026-11-07 05:04:38 -05:00
2026-11-07 05:04:38 -05:00
2026-11-07 05:04:38 -05:00