Pokemon Snap; Object detection & CPU rendering

[Beanow]

I found the same issues from this thread gonetz/GLideN64#380 apply to this plugin. However I wasn't able to fully grasp what is going on here, so I got stuck debugging this.

Anyone more familiar with these mechanisms who can point in the right direction?

[Narann]

It's a known depth hack n64 devs use in Pokemon Snap to extract informations from what's on screen:

https://fr.dolphin-emu.org/blog/2015/06/01/dolphin-progress-report-may-2015/#40-6204-use-proper-floating-point-depth-precision-by-armada-phire-and-fiora

[Beanow]

Thanks! Interesting read. However I think this is working with at least enough accuracy to support the picture analysis by Dr. Oak at the end of a trial.

From what I can gather the default values in the ini file set fb_render = 1 which will enable a software depth buffer: src/Glide64/DepthBufferRender.cpp

With everything on default in the v2.5 bundle except resolution (using 1332x999 windowed) and switching to this video plugin there are the following issues:

1. The pictures show up corrupted at Dr. Oak's analysis phase. Fixed using Pokemon Snap fb_read_always = 1 #74 (fb_read_always = 1)
2. During a trial, the camera does not detect pokemon (showing a red dot, playing a bleep, displaying a name, etc. check this video for reference of how it should respond https://youtu.be/dFHgf_SY5CY?t=3m10s).

The second issue is what I'm trying to resolve now. Because it breaks several game mechanics. One of which is that some pokemon respond to having their pictures taken. Which now they do not.
Another is the so called pokemon signs, they are pokemon resembling shapes in the scenery, which is not normally analysed at the end of the trial like normal pokemon, but during the game.

[Beanow]

Reporting what I've found so far.

Oak's evaluation requires the following things.

To render the pictures correctly, fb_read_always = 1. (See #74)
Otherwise they show up corrupt (fb_smart = 1) or black (fb_smart = 0).
This implies, fb_smart is missing ucode instructions, or has a bug in those implementations.

fb_read_always = 0, fb_smart = 1 ^

To evaluate the pictures and detect pokemon in them, fb_render = 1 and fb_smart = 1.
The (software) depth buffer emulation is required to analyse pictures as was mentioned. And without fb_smart this software depth buffer does not seem to work.

fb_render = 0 ^

For this all, RDRAM access to the aux framebuffers is required by the CPU. Meaning fb_hires = 0 is required, because otherwise the RDRAM doesn't have current data.

Course camera requires the following things.
Note: most of this information I got using GLideN64 tests (gonetz/GLideN64#380)

Displaying the red dot, pokemon information, etc. requires the CPU to draw on RDRAM framebuffers and writing those back to the GPU. I'm guessing this is read_back_to_screen = 1 or read_back_to_screen = 2. But was not able to find the implementation of these config values in source to confirm. Nor was I able to reproduce a functioning red dot with glide64mk2 to prove this.

To get the red dot's detection working during the course, aux framebuffers need to be available in RDRAM for the CPU at the right time per frame. That is, both the colour buffers and the depth buffers. It looks as though the legacy Glide64 design is unlikely to pull this off correctly when reading http://gliden64.blogspot.nl/2013/11/frame-buffer-emulation-part-i.html