Emulator Issues #5070

Legend of Zelda Skyward Sword Texture Overlay issues D3D11 and OpenGL

Added by Anonymous over 9 years ago.

% Done:


Operating system:
Issue type:
Relates to usability:
Relates to performance:
Relates to maintainability:
Regression start:
Fixed in:


1) The Legend Of Zelda Skyward Sword SOUE01

2) What is the expected output? What do you see instead?
Textures to be in the background, not overlayed on top of link.

Dx9 works fine:
Dx11 has the issue:

Tried rolling back the change that fixed the banding, isssue was still present.
Might be related to this graphical anomaly:

3) Did the game ever work correctly (i.e. not have this problem) on an
earlier version of dolphin? Please specify the exact revision when the
problem began.

4) What steps will reproduce the problem?
1.Enter the room in the pirate base in lanaryu desert.

5) What version of dolphin are you using (32bit/64bit along with the
version as it appears in the title bar, etc)?
On what operating system, drivers, and hardware? Be sure to list OS,
graphics driver information, and video card model if you are having
graphics problems, for example.

6) Please provide any additional information below.

7) Attachments. IMPORTANT! We have a limited storage quota on
GoogleCode, so please use a 3rd party host for screenshots or any other
files ( for example).


#1 Updated by Anonymous over 9 years ago

Wrong link for the possibly related image: is the correct one.

#2 Updated by delroth over 9 years ago

Can you upload a save just before this point in the game so that we can reproduce the bug easily?

#3 Updated by Anonymous over 9 years ago

Uploading now, its ~40Mb will take a few minutes

#4 Updated by Anonymous over 9 years ago

Entrance is to the right iirc.

#5 Updated by Anonymous over 9 years ago

My understanding was you just drop them into whatever folder contains "574d3545" under the "Dolphin/Wii/Titles" area.

#6 Updated by delroth over 9 years ago

TCR + DX11 does not use the same format for EFB to Texture Z16L copies. That may be why it is not happening on TCR. However I don't know why it's not happening with other backends on current master.

#7 Updated by danialhorton over 9 years ago

so this isn't a new bug then

can be closed or merged with the other many "game has issue with efb to texture" bugs.

#8 Updated by krazubu over 9 years ago

I'm not sure I understood the issue you're talking about. If it's about the collision bug where link is walking through the floor, I can tell that this also happens regularly with EFB to RAM. I played and finished the game with DX11 and EFB to RAM and still regularly got that bug in the places that get modified by those stones.

#9 Updated by nop_jne over 9 years ago

@kraz. This is not a collision bug, Link is not walking through the floor. The depth buffer is incorrectly offset, causing part of the scene to be drawn on top of existing geometry, therefore creating the illusion that Link is tunneling through objects. How ever this is not the case and if you select EFB to RAM the scene renders correctly. I presume you had EFB to Texture if you saw the incorrect depth effect. Would you be able to double check ?

#10 Updated by nop_jne over 9 years ago

I've made some progress in figuring out what is creating this artifact.

The depth copy shader in dx11 assumes it can shift up the values from the 24bit Depth buffer and distribute that into a (Z24X8) color buffer without loss of precision. This works on Dx9 but has inaccuracies on dx11. This manifests itself like this:
Orig Value| (frac(x * 255.0f) / 255.0f)
0.998059 | 1.0f | <-- this error creates a (hard line) artifact
0.998054 | 0.996078 | <-- acceptable error

Food for thought: These crude mods to the depth copy shader, reduce the artifacts which are up close, but at the same time introduce others. (This does not handle artifacts which are futher away.)
const char depth_matrix_program_msaa[] = {
"sampler samp0 : register(s0);\n"
"Texture2DMS Tex0 : register(t0);\n"
"uniform float4 cColMatrix[7] : register(c0);\n"
"void main(\n"
"out float4 ocol0 : SV_Target,\n"
" in float4 pos : SV_Position,\n"
" in float2 uv0 : TEXCOORD0){\n"
"int width, height, samples;\n"
"Tex0.GetDimensions(width, height, samples);\n"
"float4 texcol = 0;\n"
"for(int i = 0; i < samples; ++i)\n"
" texcol += Tex0.Load(int2(uv0.x*(width), uv0.y*(height)), i);\n"
"texcol /= samples;\n"
"float4 EncodedDepth = frac((texcol.r) * float4(1.0f,256.0f,256.0f*256.0f,15.0f));\n"
"EncodedDepth.r = texcol.r * 1.0019f;"
"texcol = EncodedDepth ;\n"
"ocol0 = float4(dot(texcol,cColMatrix[0]),dot(texcol,cColMatrix[1]),dot(texcol,cColMatrix[2]),dot(texcol,cColMatrix[3])) + cColMatrix[4];\n"

Modified shader:

#11 Updated by Billiard26 over 8 years ago

  • Issue type set to Bug
  • Category set to gfx

#12 Updated by velocity7 over 7 years ago

Still exists as of 4.0-112, DX11, 64-bit. To clarify, it's not just in the pirate base. It seems to be in dungeons where Timeshift Stones are activated in general.

With Timeshift Stone active:

#13 Updated by velocity7 over 7 years ago

Heads up: Since the glsl-master merge from 3.5-1025, the issue now appears in OpenGL mode as well. Hacked Buffer Upload/Vertex Streaming Hack has no effect. Only DX9 will work past 3.5-1025 for this issue.

#14 Updated by degasus over 7 years ago

Can someone please record a fifo log of this issue?

#15 Updated by velocity7 over 7 years ago

I started the recording just before I activated a Timeshift Stone where the issue occurs, and ran for a bit while the effect was active.

#16 Updated by MayImilae over 7 years ago

  • Status changed from New to Accepted

Confirmed velocity's findings via fifolog. It happens in OpenGL now too.

Also, why wasn't this accepted? Seriously it's been reproduced a hundred times. >_<

#17 Updated by velocity7 over 7 years ago

Sorry about the huge 700-frame FIFO thing there. I've made some 10-frame versions instead to better illustrate the issue: -- Timeshift Stone inactive -- Timeshift Stone active -- Timeshift Stone active, static

Just a word of note, I'm thinking that only Timeshift Stones that move actually have this issue. Ones that are fixed in place don't appear to cause this problem.

#18 Updated by velocity7 over 7 years ago

As a heads up, since D3D9 has been removed as of 4.0-155, there won't be any workarounds for the time being. If anyone is annoyed with the issue, please use 4.0-146 or earlier.

#19 Updated by JMC4789 over 7 years ago

I'm checking the fifos and they appear to render correctly when you have EFB2Ram on. I don't have a savestate in a newer version to check it in game myself.

Matches Software Renderer and Matches D3D9 on EFB2Texture.

#20 Updated by JMC4789 over 7 years ago

Also, the other EFB2Ram issues (character problems, at least) except for the blurring of the background have been solved. This area works fine on EFB2Ram. The only thing troubling is that it worked on EFB2Tex on D3D9 and Old OGL, but that could have been from things not being emulated, making it so the effect it's pulling off works by coincidence.

#21 Updated by Autoran1 about 7 years ago

You're right old OGL renders it correctly with EFB2Tex, and the code somewhere inside the OLD GLSL-master revs

#22 Updated by Autoran1 about 7 years ago

Rev GLSL-master 616 made it look this way

#23 Updated by Autoran1 about 7 years ago

Almost fixed by this
Except the lower part of the shift should not be visible

#24 Updated by Autoran1 almost 7 years ago

This is clearly the texturecache issue
according to my tests only changes to texturecache made this look different,
first time this was broken by r7cec31dbf3af, many thing were changed since than but it's still the same piece of code
so i've made a little patch
it fixes issue 7007, and almost fixes this one for OGL
it seems galop1n made smth equal in his unreleased code to fix it for D3D

#25 Updated by degasus almost 7 years ago

Autoran: sorry, this patch is invalid. But as it affect this issue, it's likely because of a broken efb2tex depth shader. They aren't tested well :/

#26 Updated by JMC4789 almost 7 years ago

It's likely whatever galop1n did to fix Skyward Sword fixed the fog in the other issues, then?

#27 Updated by JMC4789 over 6 years ago

  • Status changed from Accepted to Fixed

Also available in: Atom PDF