pokemon snap missing red dot
purplemarshmallow opened this issue · 46 comments
With angrylions plugin a red dot appears if you aim at a pokemon. If you take a picture the name of the pokemon appears on the screen. This is not working with gliden64. Also some events are not activated because of this. For example some pokemon move if you take a picture
Jabo used software rendering to fix it
Is it possible to fix it without using software rendering?
Unlikely. I guess the game checks for these pixels in RDRAM color image and will not work if these pixels are not copied.
Sorry to take up your valuable time, @gonetz, but could you explain the technical reason why this pixel checking behavior can't be done without software rendering? (This problem seriously affects Snap and Body Harvest. I suppose it's a blessing no other games seem 100% reliant on it.)
Also, would you ever add software rendering to GLideN64 the way Jabo did for his plugin? Slow, sure, but it's not impossible to multithread software renderers. (Granted, that lies far outside the scope of what GLideN64 promises.)
It can't be done without software rendering because that data must be in RDRAM to be accessible by CPU. That's my guess.
GLideN64 already has elements of software rendering for simple cases where some data must be copied to particular place in RDRAM. Complete software render is out of everything.
Excuse my ignorance, @gonetz but what is preventing you from copying the necessary data to RDRAM?
Just lack of time. I'm currently under heavy time pressure with pre-release tasks. Too much things to do. I'll return to that problem and to other problems when I'll settle with more urgent tasks.
Okay. Well, hopefully you can address the problem eventually. You'll make a lot of people (or at least people dying to play Body Harvest and Pokemon Snap) happy if you can fix this problem. Keep up the good work.
I got it working!
here's what I did:
- I played using angrylion's plugin
- I went to an area where your vehicle stands still, ideal for testing
- I made a savestate and laoded it with GLideN64
My findings:
-The red dot is a CPU based effect, "Render frame buffer as texture" must be enabled
-Enabling "Render frame buffer as texture" causes some glitches if "Copy frame buffer to rdram" is enabled, the screen starts to shake and there's flickering
-The red dot can appear although it should not appear
-The names of the pokemon appear, but it's not always accurate
here's the savestate: https://drive.google.com/file/d/0B7Y6r4SpC_QQa09ibnpyejBvbVE/view?usp=sharing
All screenshos are taken with GLideN64:
I made another experiment
I played the second level "Tunnel". At the beginning I zoomed at Pikachu and made a Savestate using angrylion's plugin. Then I loaded it and played the whole level using GLideN64. I disabled all framebuffer settings exept "Render frame buffer as texture" to see the red dot. At the end there's a pokemon which does not appear at any other point in the game, only at the end of "Tunnel". I took a picture and the name showed up. But how does the game know? Does it check for pixels in colorbuffer, but copy color was disabled the whole time. Is it a depth buffer based effect, depth buffer emulation was also disabled.
Using an Angrylion save state will also make Body Harvest work temporarily with Jabo and such. I wonder whether there could be some fundamental mishandling of colour/depth buffer data involved -- maybe floating point values or something? I'm just guessing - the fact Dolphin can play the game has promising implications.
I wonder why Jabo's software renderer works
I’ve discovered something interesting. If I enable copy to RDRAM and copy from RDRAM at the same time with the latest version of the plugin I can see all the objects that trigger camera detection. This does not happen with older versions of the plugin. I think because the screen update setting was modified.
Why is it broken in hardware gfx plugins?
I have two guesses
Color buffer is copied at the wrong time: Software gfx plugins don't need to fill the colorbuffer. Hardware gfx plugins fill it always at the same time. Maybe the modified image is overwritten. This might be easy to fix. Maybe use a hack that checks for black pixels do determine the right time.
Color buffer is filled with incorrect data: Hardware gfx plugins convert data from the video card into N64 format. Maybe this conversation process is not accurate enough and the colors don’t match.
how I do to have red dot? what emulator I need and how I set it up?
I hate to write this but if you want to play pokemon snap your best option is to run the VC version in dolphin. Angrylion's plugin also works but it's slower
I noticed with Rice Video's "with emulator" fb option and 1964 pokemon are detected! It does not work well but you can get past the tutorial.
I guess all you have to do to get this game working is accurate framebuffer emulation. If the CPU reads from a buffer then copy it to RDRAM. If the CPU writes to a buffer then copy it to the video card. The emulator and the gfx plugin must work together it can be tested if Mupen64's or 1964's implementation is good enough.
Very promising news. I haven't had time to test myself, but do these settings show any improvement for Body Harvest?
Not sure Body Harvest does not work properly for me with 1964
Not sure Body Harvest does not work properly for me with 1964
It's unfortunate that 1964 1.1's recompiler is broken in that game. However, I believe the interpreter still works. Just be sure that Timing Control is either set to "Delay DMA and SI" or "Delay DMA, SI and AI".
@purplemarshmallow I've been unable to reproduce your success with Snap using 1964 1.1 and various builds of RIce.
I used Rice Video 6.0.0. Make sure framebuffer R/W is enabled in the 1964 rom properties and use DirectX. It does not work correctly but I see it as success that you can get past the tutorial without cheats. Not sure if Rice Video can handle the 8x8 auxiliary buffers properly.
Still nothing for me, unfortunately. No red dot, controls locked, etc.
fixed!!!
works in my FB to RDRAM branch
But Oak's check will not work because of wrong depth buffer emulation
Here's my branch: https://github.com/purplemarshmallow/GLideN64/tree/FB2_RAM It's very messy and based off an old version. But works very well and accurate. No more problems with validity checking. And camera detection works!
binary: https://drive.google.com/file/d/0B7Y6r4SpC_QQRUxXWmtobmZnVEk/view?usp=sharing
@purplemarshmallow Wonderful news. Does this work with PJ64, or does it need 1964/mupen? Also, will there be any major problems merging this into the current repo since it's based on an old version?
it works with PJ64 as well
there should be no major problems but it conflicts a bit with the async fb commit
also it will need an option in the GUI
it works with PJ64 as well
Excellent. I'll test some problematic games later on.
also it will need an option in the GUI
This strikes me as the sort of improvement that should be enabled by default. Am I wrong? What are the possible negative side effects?
What are the possible negative side effects?
It's a bit like dolphin's efb to ram and efb to texture. Performance is worse. Also there are some bugs. Some games that use auxiliary buffers for shadows will just crash currently (Conker, Jet Force Gemini)
Edit: also it does not allow upscaling
Ah, I understand what you've done now. Yea... It seems to me that this sort of setting should be off by default, forced for stuff like Snap, but also listed in the main configuration window as some sort of "Native Resolution/Accurate Framebuffer" option.
Camera detection is fixed with the copy auxiliary option. But the red dot is still missing. It's drawn by the CPU. To see it you have to enable copy from RDRAM. The game will render in native resolution.
Copy from RDRAM should be improved. I think this can only be done with a notification from the emulator. I'd still say this is fixed. @phire your information was useful
Currently I'm trying to resolve the same issues with mupen64plus-video-glide64mk2. Could you elaborate a bit more on what the game is attempting to do and what the emulator & video plugin need to support to get it to work?
I can live with CPU rendered overlays not being displayed but the pokemon events and signs are currently broken in my config with the other plugin.
Gonetz can explain it much better, but the game has three basic tricks.
1: It writes red pixels to the framebuffer for the camera red dot. This works fairly well if you can only write those pixels into the final framebuffer. But that's not widely supported by emulators. Copying the buffer from RAM causes everything to shake, so that's not ideal currently.
2: Detecting Pokemon requires the auxiliary framebuffers to be copied to RAM. These are usually skipped. GLideN64 can copy them using its copy Aux to RAM function, but this is currently slightly/majorly bugged and while it allows Pokemon photography to work, it breaks Professor Oak analysing them.
3: The game needs reasonably accurate depth buffer emulation for Oak's Pokemon scoring to work. Glide64's software depth buffer, which was ported to GLideN64, seems to work well enough.
I think there might be some other issues with mupen64plus. I'm fairly sure PJ64's "delay DP interrupt" hack is what makes the game actually work properly for the emu. I don't know whether mupen64plus can run it, even with Angrylion's plugin. I recall that vanilla 1964 can't handle the game.
Also, all the "cheat" hacks used to make the game "work" by PJ64 and Mupen basically break the game and should never have been implemented.
Thanks! Like you said in 3, the software depth buffer is being used and the analysis at the end of the game works.
But 1 and 2 do not. There's no red dot, nor names, nor bleeps, nor do pokemon events trigger based on being snapped, nor do pokemon signs function properly.
So if I understand correctly the process during a trial to detect pokemon is a loop of:
- Render the scene to gfx buffers.
- Copy the buffers to RAM.
- Let the CPU analyse the RAM buffers if we've got a pokemon in our sights.
- Let the CPU draw over the framebuffers in RAM to apply red dots and the likes.
- Copy the RAM buffers back to the graphics card.
How is copying the aux buffers to RAM related to breaking analysis at the end though? Are the software depth buffer and aux buffer copying mutually exclusive?
How is copying the aux buffers to RAM related to breaking analysis at the end though? Are the software depth buffer and aux buffer copying mutually exclusive?
There's something wrong with auxiliary copies. #882 I think something is probably being overwritten or corrupted.
But 1 and 2 do not. There's no red dot, nor names, nor bleeps, nor do pokemon events trigger based on being snapped, nor do pokemon signs function properly.
Mupen64plus is broken with the game. And it has hacks in its ini files to "fix" the game that break it even more. The game's controls do not unlock until you snap the first pokemon. So a hack was added, which was a bad diea.
Gonetz can explain it much better
You seems to know the situation much better than me :) And you explained it well, I can add nothing useful to what is said.
@gonetz actually your blogpost http://gliden64.blogspot.nl/2013/10/frame-buffer-emulation-intro.html helped a lot for the basic understanding of how buffers are used.
Trying to run with GlideN64 now (built from master branch) and I'm getting a number of fascinating effects here.
Is this the auxilary frame buffers being copied from the main frame buffer?
Which options are you running with and where do I set those in mupen64plus?
Fascinating situation here. On mupen64plus with the below settings related to FBs I'm getting detection of pokemon (that is, both in-game with dots and bleeps, as well as after the game) that are located in completely different places! Some visual glitches as well.
This may be related to #882's corruption issues. Like was suspected by @AmbientMalice there.
[Video-GLideN64]
# Swap frame buffers (0=On VI update call, 1=On VI origin change, 2=On buffer update)
BufferSwapMode = 0
# Enable writing of fragment depth. Some mobile GPUs do not support it, thus it made optional. Leave enabled.
EnableFragmentDepthWrite = True
# Enable frame and|or depth buffer emulation.
EnableFBEmulation = True
# Copy auxiliary buffers to RDRAM
EnableCopyAuxiliaryToRDRAM = True
# Enable N64 depth compare instead of OpenGL standard one. Experimental.
EnableN64DepthCompare = False
# Disable buffers read/write with FBInfo. Use for games, which do not work with FBInfo.
DisableFBInfo = True
# Read color buffer by 4kb chunks (strict follow to FBRead specification)
FBInfoReadColorChunk = False
# Read depth buffer by 4kb chunks (strict follow to FBRead specification)
FBInfoReadDepthChunk = False
# Enable color buffer copy to RDRAM (0=do not copy, 1=copy in sync mode, 2=copy in async mode)
EnableCopyColorToRDRAM = 1
# Enable depth buffer copy to RDRAM (0=do not copy, 1=copy from video memory, 2=use software render)
EnableCopyDepthToRDRAM = 2
# Enable color buffer copy from RDRAM.
EnableCopyColorFromRDRAM = TrueMupen64plus is broken with the game.
I've seen this mentioned a few times. Can you elaborate? I just played through the first level, and everything worked perfectly, including Prof. Oak's checks. I removed the cheats from the ini and submitted a PR to have them removed. It all worked.
Everything worked except the red dot, which requires CopyFromRDRAM, but that setting causes flickering. But that is the same in Project64. Plus the red dot is just a cosmetic thing, so the game is still fully playable.
I'm just curious what issues you've ran into with mupen64plus so I can see if I can sort them out.
Plus the red dot is just a cosmetic thing, so the game is still fully playable.
You sure about that? Certain events in the game are triggered by looking at Pokemon, which from memory requires a working red dot.
Certain events
If you can be more specific I can test it out, but I believe it is the opposite, the red dot is triggered by looking at Pokemon. I think people just assumed the red dot was responsible because it wouldn't show up unless a Pokemon was detected, but it's not actually the red dot that is doing the work. I could be wrong though.
It's been a while. But if I recall correctly the issue is pokemon sign detection works differently as well as a door lever at some point. Maybe check if the kingler rock on the left at the start of the first trial works for you.
What is supposed to happen when I take a picture of that rock? It shows a ? (taking a picture of Snorlax in this level does the same thing). When you go to Prof Oak's check it says something like "hmm this picture is not clear".
Enabling CopyFromRDRAM causing flickering, but the red dot is there, and when I take a picture of the rock, the red dot appears, but I still get the ? identifying it.
Looking at a YouTube video it appears that it should be saying Sign?? New. However, like I mentioned, even with enabling CopyFromRDRAM and having the red dot appear, it still does not work, so something else it wrong.
I was under the impression that this game only worked with a software renderer. Is Pokemon Dano working with GLideN64 for others?
Is Pokemon Dano working with GLideN64 for others?
I assume "Dano" is a strange autocorrect of "Snap"? Anyway yes, it works, you can take pictures and have Prof Oak rate them. It seems that's it's not perfect at detecting what you've taken a picture of, and the red dot doesn't appear when you have a Pokemon in your sights, but it is playable.
Ah. I might have an answer for this. This issue occurred on another plugin too but was resolved. It was multi threading issue. Maybe @gonetz can build a test plug that has MT disabled to test further??
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.