Emulator Issues #8299closed
Metroid Prime sometimes overrides textures with EFB Copies (Store EFB Copies to Texture Only)
Metroid Prime - GM8E01
What's the problem? Describe what went wrong in few words.
When using Store EFB Copies to Texture Only, once in a while, a random texture(s) in the next room will get overridden from an EFB effect from the previous room. Swapping the option off/on will fix the problem.
What did you expect to happen instead?
I expected Store EFB Copies to Texture Only to be fully functional in Metroid Prime after the Paletted Texture fixes.
What steps will reproduce the problem?
- Play the game for a while. The longer you play it the more likely it is to happen. Happened twice in about an hour for me.
- Keep your eyes open for it, sometimes it is a subtle panel on the ceiling, other times entire walls are missing.
Dolphin 3.5 and 3.5-367 are old versions of Dolphin that have
known issues and bugs, so don't report issues about them and test the
latest Dolphin version first.
Which versions of Dolphin did you test on?
Does using an older version of Dolphin solve your issue? If yes, which
versions of Dolphin used to work?
No; there have been reports of this happening for a very long time; I just didn't know why until recently.
What are your PC specifications? (including, but not limited to: Operating
System, CPU and GPU)
Core i5 3570K, GTX 760, Windows 7 x64
Is there any other relevant information? (e.g. logs, screenshots,
Note: One screenshot is darker than the other due to a geyser in the room going off and whatnot.
These were taken in the same run, when swapping the option, it will instantly fix itself. Even weirder, I recorded the fifolog when it was still broken, but when playing back the fifolog, even in EFB Copies to Texture. I'm confused.
The reason this issue is semi-important is that it seems to be the only thing blocking Metroid Prime from working without EFB Copies to Texture.
Updated by magumagu9 about 9 years ago
efb2tex currently completely ignores everything except the address when dealing with EFB copies, including any changes to the contents of the memory in question. This means if a game uses an address for both efb copies and regular textures, it won't work properly with efb2tex. It's possible the current tradeoff isn't quite right; we could experiment with adding hashes for efb2tex copies. (I'm not 100% sure that's the issue, but it's my best guess.)
Updated by phire about 9 years ago
Could also use the same kind of trick that hybrid xfb uses.
When a copy is triggered, write a key value (probably zeros) to the ram, and before using it, check the ram still contains zeros.
Would be faster than hashing and it would catch the case where a game overwrites a texture with an efb copy and then re-loads the exact same texture from disk later.
But it would make a few cases which efb2tex is currently kind of broken (no spinning coins in NSMB) more broken (coins get replaced by a blank or transparent texture)
Updated by mimimi about 9 years ago
If the game really uses the same offset for an efb copy and a normal texture, what about adding a check for some more parameters? It makes sense to not check the format, because right now Dolphin has 2 sets of texture formats, one for efb copies and one when loading textures. But what about checking native width/height for example?
Also, if Dolphin loads a texture and it's supposed to be an efb copy, can we assume the efb copy was created during the same frame?
Both ideas might fix the issue, but they would be just better assumptions, not a real solution. So i guess this means that hashing efb copies for efb2tex really needs to be tested. There goes the idea of skipping hash calculation on efb copies for efb2tex on load as well...
Updated by phire about 9 years ago
We can't assume an efb copy was created during the same frame, many games create an efb copy and use it across multiple frames.
Checking the texture format doesn't really work either. At the time of the efb copy, we don't know what format it's going to be rendered in.
The only reliable way to tell if an efb copy has been replaced with a loaded texture is to somehow detect the write to memory.
Updated by guitaristocrat3 over 8 years ago
Still happens for me in Harry Potter Sorcerer's Stone in master (4.0-6789) and EFB2RAM still fixes it. I tried single core too and the glitch occurs with that as well. http://i.gyazo.com/bd0ae887249dcc9b7237c38dd8ef4e2f.png
Updated by Autoran1 over 8 years ago
the easy way to reproduce it on older builds is to enter in morphball mode than exit form it and issue will appear on Thermal or X-Ray visors, or on the locations walls
The issue is fixed for me, can't reproduce it on this build anymore, Thanks
Updated by JosJuice over 8 years ago
- Status changed from Accepted to Fixed
I suppose the issue is fixed, then. Merged in 4.0-7630: https://dolphin-emu.org/download/dev/1f800b80ddef7e6ca7763605e9e2209892f48a61/
Should EFB2RAM be removed from the Metroid Prime game INI?