Emulator

golivax wrote:

Game Name?

The Legend of Zelda: Twilight Princess

Game ID? (right click the game in the game list, Properties, Info tab)

GZ2E01

MD5 Hash? (right click the game in the game list, Properties, Verify tab, Verify Integrity button)

41deff9b1fd2831f48fbfa2dd1054e4d

What's the problem? Describe what went wrong.

Disabling "Scaled EFB Copy" when using Vulkan and increased internal resolution (e.g., 2x), the map becomes garbled. The end result is similar to that of turning on AA when using native resolution.

What steps will reproduce the problem?

• Set backend to Vulkan
• Increase internal resolution (e.g., to 2x)
• Disable Scaled EFB Copy
• Boot up the game, create a new quest log. When gameplay starts, you'll be able to see the corrupted map.
• Map seems to remain corrupted in all other areas of the game

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

5.0-20048

Is the issue present in the latest stable version?

Yes

If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)

[First broken version number here (if applicable)]

If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer

[Attach any fifologs if possible, write a description of fifologs and screenshots here to assist people unfamiliar with the game.]


What are your PC specifications? (CPU, GPU, Operating System, more)

Tested on an Asus Rog Ally (AMD Ryzen Z1 extreme, 16GB Ram) and on a Thinkpad T480 (Intel integrated graphics, 32GB Ram). Windows 11 on both
Exact same problem with both machines. So probably not a driver issue.

Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)

N/A

Now checking the screenshot more carefully, I notice another problem: the upper left part of link is blurrier than the rest of his body. This is true in the very first area of the game as well.
This screenshot was taken on the Thinkpad, but I'm having the exact same problems (corrupted map, blurry link) on the ROG Ally as well. Weird.

Can you attach a fifolog? You can compress it with 7-zip if it ends up being too big to attach directly.

Hmm, something doesn't seem to be working right with that fifolog; only the hearts show up and if I change the object range stuff is mostly off screen. But I'm also able to reproduce the issue with https://fifo.ci/media/dff/ztp_grass.dff which works fine.

The top-left of the screen being blurry is expected: the game prepares its bloom effect by making a copy of the top-left of the screen, then repeatedly drawing over the top-left of the screen to actually do the bloom, then restoring the original EFB copy. (This is the standard approach for GameCube/Wii games since there is only one framebuffer, so you can't prepare the bloom effect in an off-screen area.) If you turn off "scaled EFB copy", then that automatically will be at 1x resolution, and there's no way to change that ("scaled EFB copy" is the solution).

It looks like the map renders incorrectly at even IRs (e.g. 2x, 4x, 6x), but is fine at odd ones (e.g. 1x, 3x, 5x). With "scaled EFB copy" disabled, you can get identical results for all odd IRs by just picking the center pixel in each group, but on even ones that isn't possible. I'm not sure where the purple bits come from though, and maybe there's a way to work around it. The easiest workaround would be to use 3x IR instead of 2x IR or enable "scaled EFB copy" though.

pokechu22 wrote in #note-4:

Hmm, something doesn't seem to be working right with that fifolog; only the hearts show up and if I change the object range stuff is mostly off screen. But I'm also able to reproduce the issue with https://fifo.ci/media/dff/ztp_grass.dff which works fine.

The top-left of the screen being blurry is expected: the game prepares its bloom effect by making a copy of the top-left of the screen, then repeatedly drawing over the top-left of the screen to actually do the bloom, then restoring the original EFB copy. (This is the standard approach for GameCube/Wii games since there is only one framebuffer, so you can't prepare the bloom effect in an off-screen area.) If you turn off "scaled EFB copy", then that automatically will be at 1x resolution, and there's no way to change that ("scaled EFB copy" is the solution).

It looks like the map renders incorrectly at even IRs (e.g. 2x, 4x, 6x), but is fine at odd ones (e.g. 1x, 3x, 5x). With "scaled EFB copy" disabled, you can get identical results for all odd IRs by just picking the center pixel in each group, but on even ones that isn't possible. I'm not sure where the purple bits come from though, and maybe there's a way to work around it. The easiest workaround would be to use 3x IR instead of 2x IR or enable "scaled EFB copy" though.

Thanks for the analysis! Not sure what happpened with my fifolog, but I'm glad that you managed to reproduce the error.

And you're right, I had forgotten to mention that Scaled EFB Copy (ON) works fine with odd IRs. And thanks for the explanation about the blurriness/bloom.

So just to give some context, what I'm trying to achieve with the graphical settings is an image that's very true to the original hardware with just slightly less jagged edges. Hence the 2x + scaled efb copy off. This worker very well in Skyward Sword. The almost "watercolor"-like art of the game (e.g., far away trees) is totally preserved, since it's drawn at native resolution. Also, all the bloom stuff and other effects are preserved. So I'd love to be able to stick to that configuration on Twilight Princess.

Bumping IR to 3x makes the "vector stuff" too sharp compared to textures, etc. And then I get distracted and the fun goes away haha.

Tks for the investigation! Maybe the vulkan folks could take a quick look? I know they have been quite busy with code reviews and stuff though, so I totally get it if this has to wait for a while. Tks again!

pokechu22 wrote in #note-4:

It looks like the map renders incorrectly at even IRs (e.g. 2x, 4x, 6x), but is fine at odd ones (e.g. 1x, 3x, 5x). With "scaled EFB copy" disabled, you can get identical results for all odd IRs by just picking the center pixel in each group, but on even ones that isn't possible. I'm not sure where the purple bits come from though, and maybe there's a way to work around it. The easiest workaround would be to use 3x IR instead of 2x IR or enable "scaled EFB copy" though.

I've been enjoying playing games at 1xIR and high SSAA lately. Is there any chance we could have odd multipliers for SSAA (e.g., 3x, 5x, 7x)? Since the map bug doesn't occur with odd IRs, I assume that using odd SSAA multipliers would not trigger the bug as well. From a less selfish perspective, I assume other people might enjoy having a more fine-grained control over SSAA too ( since it is quite taxing on the GPU). Thanks!

From a specification perspective, it's technically legal (and not even limited to integers apparently, so you can have 2.5 SSAA, though I'm not entirely sure what that actually means). But in practice my understanding is that if you use a value that's not a power of 2, the driver just rounds it to the next power of 2. (We do ask the driver what AA values it supports and use those directly).

But doing SSAA without using the built-in driver feature for it is probably feasible (regular antialiasing only on the edges of polygons seems like it would need driver support, but I'm pretty sure SSAA is indeed equivalent to raising the internal resolution and then averaging those values, perhaps apart from choice of sampling locations), though it might take a little bit of work. It could probably be done using Dolphin's existing postprocessing shader system.