Pokemon Snap Red dot doesn't work Android

[fzurita]

The Pokemon snap red dot doesn't seem to work in Android. I tried copying these settings and it still doesn't work:
frameBufferEmulation\copyAuxToRDRAM=1
frameBufferEmulation\copyToRDRAM=1

In addition, I enabled copy color buffer from RDRAM.

Is there some other setting I'm missing to get it to work?

[gonetz]

Try to enable FBInfo.

[fzurita]

It doesn't work in android since the ARM new dynarec doesn't support it. Although, it works in project 64, which doesn't support that, right?

[gonetz]

project 64 does not support FBInfo, but mupen64plus for windows does. I'm not sure that FBInfo fixes all the issues with Pokemon Snap, and it could ad some new as well. Anyway, FBInfo is the best approach to support features such as Red Dot. Other methods are even less reliable.

[CallistoNTG]

frameBufferEmulation\copyToRDRAM=1

Shouldn't that be frameBufferEmulation\copyToRDRAM=2? I thought Snap required the software depth buffer.

[fzurita]

@gonetz I meant the red dot works fine in project 64 without FB info.

[fzurita]

@CallistoNTG I do have that enabled and the red dot still doesn't work. The configuration you quoted is for copying color buffer to RDRAM.

[DonelBueno]

#380

I think this is the reason for it not to work:

"The red dot will appear with copyFromRDRAM=1, but this setting also breaks Oak's review. So we can have the red dot if we break the game."

It's a tradeoff between playability and a comestic feature.

[Jj0YzL5nvJ]

@DonelBueno, can you test using copyFromRDRAM=1 and copyFromRDRAM=2 with ThreadedVideo disabled?
See #1630

[DonelBueno]

@Jj0YzL5nvJ The game runs apparently at native resolution with these settings. The red dot appears, but oak's checks don't work, exactly as described on #380.

[ghost]

I can get the red dot effect to work by disabling the memsets introduced in 538674d

Edit: Sorry I explained myself wrong, disabling the memsets makes the oak check work with copyFromRDRAM enabled.

[fzurita]

Yeah, I don't think that hack I introduced is needed any more since we have the FB info API in mupen64plus. The only downside of that API is that it requires interpreter instead of dynarec.

[ghost]

Yeah, I don't think that hack I introduced is needed any more since we have the FB info API in mupen64plus. The only downside of that API is that it requires interpreter instead of dynarec.

Ok, so is it fine if I remove it and pull request?

[fzurita]

Yeah, I think so.

[ghost]

@fzurita Can you check if it is working on Android?

[fzurita]

Unfortunately, still no red dot in Android. Not sure what the difference is.

[fzurita]

This is really odd though, even with copy all of RDRAM to GPU memory, the red dot is not there. It's almost like it's not being drawn by the CPU.

Edit: More than likely, it's being overwritten by the video plugin somehow.

Edit: This used to work fine even before you reverted that code. Probably the easiest thing to do would be to bisect which commit broke it. This is still difficult though since it's hard to go back before CMake.

Edit: Also, the red dot is not just cosmetic, if it doesn't work, then you can't move the joystick when the game level first starts.

[ghost]

@fzurita Sorry, I didn't see the last message.

Just to make sure, this are the settings I need to emulate the game correctly in Mupen64Plus.

EnableCopyAuxiliaryToRDRAM = 1
DisableFBInfo = 0
FBInfoReadColorChunk = 1
FBInfoReadDepthChunk = 1
EnableCopyColorToRDRAM = 1
EnableCopyDepthToRDRAM = 2
EnableCopyColorFromRDRAM = 1

But it seems to me only the last one is necessary for the red dot.

I also seem to have trouble in Project 64, the game shows the red dot but doesn't detect the pkmn well. However, angrylions plugin in the same emulator works well. Strange.

[fzurita]

I have tried multiple settings, including those with no luck. I don't get the red dot.

To me, it appears that GLideN64 is overwriting what the game is overlaying on top of the image in RDRAM.

[fzurita]

This is an interesting write up about how all those effects work: https://dolphin-emu.org/blog/2015/06/01/dolphin-progress-report-may-2015/

At least how they think that they work.

[fzurita]

If I enable a cheat to allow camera movement, pokemon are detected correctly in the end when the professor grades the pictures.

[fzurita]

One thing we should make sure that we are doing is is when writing back depth to RAM is to not scale by 0xFFFF since that introduces rounding errors. In the blog entry they had to scale to 2^16. Although, given that the professor's check at the end is working, that's probably not the problem here.

Edit: And all that probably doesn't apply to us because we never read back the depth buffer from the CPU and put it in the GPU as far as I an tell.

[ghost]

If I enable a cheat to allow camera movement, pokemon are detected correctly in the end when the professor grades the pictures.

This is what the post is about and the harder effect to emulate: getting the Oak's Check to work. The red dot is likely simply written to the color buffer by the cpu. I don't know why it would fail in Android, though.

[fzurita]

Yeah, good question. It works fine with Angrylion. So it's probably something that the video plugin is doing incorrectly.

[fzurita]

Well... I found the issue. It was something silly. Red dot now works correctly in Android see pull request. Also, I can see the pokemon name when the red dot points to a pokemon and the camera becomes unlocked now after the small tutorial.