Commit Graph

19 Commits

Author SHA1 Message Date
Lioncash 776e36b10a Fix a typo in a BP register name (BPMEM_TX_SETLUT_4 -> BPMEM_TX_SETTLUT_4).
Also fixed the alignment of the register values.
2014-06-02 02:26:30 -04:00
Lioncash c96407bd2a Make GetBPRegInfo just take two strings as parameters
Gets rid of the size parameters.
2014-05-29 19:44:14 -04:00
Jasper St. Pierre 2f122ea63c BPMemory: Fix "DISPLAYCOPYFILER" typo 2014-05-20 11:15:10 -04:00
magumagu 2e464800bc VideoCommon: correctly compute whether an indirect texture stage is active.
This is consistent with the implementation in PixelShaderGen.
2014-05-04 22:44:10 -07:00
Tony Wasserka 762572a08c BPMemory: Fix GenMode using an incorrect number of bits for the number of color chans. 2014-04-21 22:47:08 +02:00
Tony Wasserka 16d3dbc5ea BPMemory: Use BitField for the GenMode fields. 2014-04-21 22:34:23 +02:00
comex b5654a2464 Don't cast -1 to enum to represent a missing value.
This is undefined behavior in C++, and a clang warning suggests it is
actually producing bad code as a result:

../Source/Core/VideoCommon/BPFunctions.cpp:164:45: warning: comparison of constant 4294967295 with expression of type 'PEControl::PixelFormat' is always false [-Wtautological-constant-out-of-range-compare]
        if (new_format == old_format || old_format == (unsigned int)-1)
2014-03-30 01:40:06 -04:00
Tony Wasserka c6070b94ce BPMemory: Fix an enum to use u32 as its underlying type. 2014-03-26 10:02:57 +01:00
Tony Wasserka 16105db709 BPMemory: Make use of BitField in a number of structures. 2014-03-25 23:57:58 +01:00
Tony Wasserka 8941f19cdb BPMemory: Expose the pixel_format and zformat fields in PE_CONTROL as enumerations. 2014-03-25 23:57:58 +01:00
Tony Wasserka 77a7bab5ae BPMemory: Use the new BitField class in two selected structures. 2014-03-25 23:57:57 +01:00
Tony Wasserka fa7173d099 PixelShaderGen: Store tex scale as an integer. 2014-03-14 22:32:30 +01:00
Matthew Parlane 31cfc73a09 Fixes spacing for "for", "while", "switch" and "if"
Also moved && and || to ends of lines instead of start.
Fixed misc vertical alignments and some { needed newlining.
2014-03-11 00:35:07 +13:00
Lioncash 2afe215271 Convert all includes to relative paths. 2014-02-18 02:19:10 -05:00
Lioncash 3fd87a7636 Second and final pass of clearing out tabs. 2014-02-17 02:19:41 -05:00
lioncash d2038049f5 Replace all include guard ifdefs with "#pragma once" 2014-02-10 18:07:16 -05:00
Lioncash ebb48d019e Clean up some struct indentations
Also cleaned up the indentations of some variable declarations.
2014-02-09 19:40:11 -05:00
Pierre Bourdon ed67d1ae2f 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.
2014-01-05 11:33:15 +01:00
Jasper St. Pierre 34692ab826 Remove unnecessary Src/ folders 2013-12-31 14:03:19 -05:00