From ed67d1ae2f9693ed42867a2e79b7cae4427574e3 Mon Sep 17 00:00:00 2001 From: Pierre Bourdon Date: Sun, 5 Jan 2014 11:16:08 +0100 Subject: [PATCH] Fix the Zelda: The Wind Waker heat effect glitch. Let's talk a bit about this bug. 12nd oldest bug not fixed in Dolphin, it was a lot of fun to debug and it kept me busy for a while :) Shoutout to Nintendo for framework.map, without which this could have taken a lot longer. Basic debugging using apitrace shows that the heat effect is rendered in an interesting way: * An EFB copy texture is created, using the hardware scaler to divide the texture resolution by two and that way create the blur effect. * This texture is then warped using indirect texturing: a deformation map is used to "move" the texture coordinates used to sample the framebuffer copy. Pixel shader: http://pastie.org/private/25oe1pqn6s0h5yieks1jfw Interestingly, when looking at apitrace, the deformation texture was only 4x4 pixels... weird. It also does not have any feature that you would expect from a deformation map. Seeing how the heat effect glitches, this deformation texture being wrong looks like a good candidate for the problem. Let's see how it's loaded! By NOPing random calls to GXSetTevIndirect, we find a call that when removed breaks the effect completely. The parameters used for this call come from the results of methods of JPAExTexShapeArc objects. 3 different objects go through this code path, by breaking each one we can notice that the one "controlling" the heat effect is the one at 0x81575b98. Following the path of this object a bit more, we can see that it has a method called "getIndTexId". When this is called, the returned texture ID is used to index a map and get a JPATextureArc object stored at 0x81577bec. Nice feature of JPATextureArc: they have a getName method. For this object, it returns "AK_kagerouInd01". We can probably use that to see how this texture should look like, by loading it "manually" from the Wind Waker DVD. Unfortunately I don't know how to do that. Fortunately @Abahbob got me the texture I wanted in less than 10min after I asked him on Twitter. AK_kagerouInd01 is a 32x32 texture that really looks like a deformation map: http://i.imgur.com/0TfZEVj.png . Fun fact: "kagerou" means "heat haze" in JP. So apparently we're not using the right texture object when rendering! The GXTexObj that maps to the JPATextureArc is at offset 0x81577bf0 and points to data at 0x80ed0460, but we're loading texture data from 0x0039d860 instead. I started to suspect the BP write that loads the texture parameters "did not work" somehow. Logged that and yes: nothing gets loaded to texture stage 1! ... but it turns out this is normal, the deformation map is loaded to texture stage 5 (hardcoded in the DOL). Wait, why is the TextureCache trying to load from texture stage 1 then?! Because someone sucked at hex. Fixes issue 2338. --- Source/Core/VideoCommon/BPMemory.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Source/Core/VideoCommon/BPMemory.h b/Source/Core/VideoCommon/BPMemory.h index 94455b04bffe..ff8650bd4a33 100644 --- a/Source/Core/VideoCommon/BPMemory.h +++ b/Source/Core/VideoCommon/BPMemory.h @@ -433,8 +433,8 @@ union RAS1_IREF }; u32 hex; - u32 getTexCoord(int i) { return (hex>>(6*i+3))&3; } - u32 getTexMap(int i) { return (hex>>(6*i))&3; } + u32 getTexCoord(int i) { return (hex>>(6*i+3))&7; } + u32 getTexMap(int i) { return (hex>>(6*i))&7; } };