search

mupen64plus / mupen64plus-video-glide64mk2

Video plugin for Mupen64Plus 2.0 based on 10th anniversary release code from gonetz
28 stars 37 forks source link

Pokemon Snap; Object detection & CPU rendering #75

Open Beanow opened 8 years ago

Beanow commented 8 years ago

I found the same issues from this thread https://github.com/gonetz/GLideN64/issues/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 commented 8 years ago

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 commented 8 years ago

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 https://github.com/mupen64plus/mupen64plus-video-glide64mk2/issues/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 commented 8 years ago

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._

No read always, smart FB _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.

No depth buffer _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 (https://github.com/gonetz/GLideN64/issues/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