Repository navigation
Fix Pokémon Snap photo check (Oak's Mark) with copy aux to RDRAM - #2991
Open
JoeysRetroHandhelds wants to merge 1 commit into
Open
JoeysRetroHandhelds wants to merge 1 commit into
JoeysRetroHandhelds wants to merge 1 commit into
Conversation
Snap's photo selection screen re-renders each photo at 64x48 and copies strips of that render's depth buffer (via texrects) to check that the Pokemon is visible. The color frame buffer GLideN64 creates when the game clears depth by pointing the color image at it was used as the texture source instead of depth, and copyAux() wrote its color over the software-rendered depth in RDRAM. Every photo then failed the check and Oak's Mark stayed greyed out. Track buffers that were only ever filled with the depth clear color. With software depth rendering, load textures from such buffers out of RDRAM and don't copy them back. Buffers with any other drawing (e.g. Mario Tennis drawing color at the depth address) keep the old behaviour.
JoeysRetroHandhelds
force-pushed
the
fix-snap-depth-strips
branch
from
November 6, 2026 04:07
5385bd3 to
156888a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pokémon Snap's photo selection screen re-checks every photo before it can get Oak's Mark. It re-renders the photo at 64x48 with a depth buffer, then uses copy-mode texrects to copy strips of that depth buffer into twelve 64x24 buffers and compares them. If the Pokémon's depth values aren't there, the game clears the photo's subject flag and Oak's Mark is greyed out. The photos are markable while they are being counted, then go grey once the player gets control.
With the Snap settings from
GLideN64.custom.ini(copyAuxToRDRAM=1, software depth copy), two things go wrong:CheckForFrameBufferTexturethen treats loads from that address as a frame buffer texture and samples this color buffer, which has no depth in it. All the strip buffers come out zero.copyAux()at full sync writes that color buffer back to RDRAM, over the depth values the software depth renderer had written there.That matches the old observation in #777 that "Aux FB to RAM must be overwriting something".
Change: frame buffers now record whether they were only ever filled with the depth clear color (
m_depthClearOnly, cleared by any other draw). WhencopyDepthToRDRAM == cdSoftwareRender:copyAux()doesn't copy such buffers back.Buffers with any other drawing, such as Mario Tennis drawing color at the depth buffer address, keep the old behaviour. Nothing changes when software depth rendering is off.
Testing: Pokémon Snap (U), Beach course, Pidgey photos. Oak's Mark now works; before this change it was greyed out for every photo. Tested through the libretro core (mupen64plus-next) on Android, Adreno 740 GLES 3.2. Not tested in standalone GLideN64 or on desktop GL, though the code path is the same.
Related: #777, #1653