Builder pack-ubu-x64 Build #227

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

Triggerable(pack-ubuntu)

Steps and Logfiles:

1. git update ( 2 secs )
   1. stdio
2. shell untar debian dir ( 0 secs )
   1. stdio
3. shell_1 update version ( 0 secs )
   1. stdio
4. shell_2 build ( 1 mins, 39 secs )
   1. stdio
5. upload uploading dolphin-emu-master_4.0-593_amd64.deb ( 0 secs )
   1. - no logs -
   2. dolphin-master-4.0-593_amd64.deb
6. shell_3 clean up ( 0 secs )
   1. stdio
7. MasterShellCommand website notice ( 0 secs )
   1. stdio

Build Properties:

Forced Build Properties:

Responsible Users:

1. Pierre Bourdon

Timing:

All Changes:

:

1. Change #1418

   Category	None
   Changed by	Pierre Bourdon
   Changed at	Sun 05 Jan 2014 10:40:03
   Revision	ed67d1ae2f9693ed42867a2e79b7cae4427574e3

   Comments

   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.

   Changed files

   • no files

   Properties

   Author	Pierre Bourdon
   Branchname	master
   Description	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.
   Shortrev	4.0-593