Emulator

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

I just noticed a lot of people talking about this issue and wanted to check it out for myself.

I bet flicking the texture cache would also fix it.

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)

I think the easiest way to trigger this bug is to lose health; every time I lose a full bar of health, the rest of the bars disappear.

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

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.

Issue 8626 has been merged into this issue.

I can't reproduce this issue any longer in master? Can someone else look into this? Was using single core, but I doubt it matters.

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

I also (accidentally) had scaled EFB Copies off, maybe that will affect things?

Managed to reproduce it again after trying a bit more, oh well.

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