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.
Changes a lot of parsing code which previously was not aware of the notion of
key/value, and operated only with raw lines. Now key/value is the default and
lines are handled as raw only if they do not contain =, or they start with $ or
+ (for Gecko/AR compatibility).
210 commits, more than 2 years of work, one of the most awaited features for
Dolphin.
Thanks a lot to Matthew Parlane and Shawn Hoffman for their work on
wii-network.
There are still a few rough edges, expect some bugs, maybe some regressions.
Please do as much testing as you can.
The code was hitting undefined behavior, causing crashes when starting a Wii
game with Dolphin compiled with gcc >= 4.8.
Might introduce some slight change in the Wiimote activation logic.
Fixes issue 6526.
Use strings internally, use a multimap and std::function for callbacks (instead
of a flat vector + loop over the vector to find the right callback type), fix
coding style issues. Simplify MainAndroid code a bit.
It's not enough to check for the CPUID bit to know if AVX is supported since
AVX requires OS support (new set of registers == more registers to be saved
when context switching). If the OS does not support, the cpuid bit will still
be set but using YMM registers will cause an illegal exception fault.
SDL2.0 removed SDL_HAPTIC_SQUARE because of ABI issues (see comment #7 on issue
6491 by Ryan C. Gordon from the SDL project). It will be reintroduced again in
2.1, so keep the code and #ifdef it away.
This reverts commit cce809ac90.
The code was actually correct: "expr" is never allocated when an error is
returned. This means when the expression parser fails, deleting "expr" means
deleting an uninitialized pointer.
Also keep a PNG version of bin2c'd resources in order to make these kind of
changes easier in the future.
Fixes recent versions of libpng complaining loudly about our images.
GC and Wii games using the AX UCode should now work almost perfectly with DSP
HLE. If you get any issue, make sure the "DSP on dedicated thread" option is
disabled, and try setting framelimit to "Audio".
As a side effect, DSP HLE should not desync anymore (making it usable in
netplay and TAS) with AX games.
Conflicts:
Source/Core/Core/Src/HW/DSPHLE/UCodes/UCode_AX.h
Source/Core/Core/Src/HW/DSPHLE/UCodes/UCode_AXWii.cpp
At the end of July 2011, LM published a free DSP ROM that works with games
using the Zelda UCode. His ROM only has the code to handle UCode loading and a
few utility functions, the rest is missing. This includes the four large sound
mixing functions used by the AX UCode and the DROM containing coefficients used
for polyphase resampling in AX.
This is an improved, updated version of this ROM, which changes the following:
- We now have a free DROM that works for polyphase resampling by "emulating"
linear interpolation. The coefficients contained in the DROM are normally a
list of { c1, c2, c3, c4 } which are used to interpolate a sample value from
four previous samples:
out_sample = prev1 * c1 + prev2 * c2 + prev3 * c3 + prev4 * c4
The coefficients are chosen depending on the fractional part of the current
position (basically, our position between the previous and the next sample).
We can use this fact to generate (c1, c2, c3, c4) for each possible
fractional part so that:
out_sample = prev3 * curr_pos + prev4 * (1 - curr_pos)
Which is the formula for linear interpolation between prev3 and prev4. Linear
interpolation is not as good as polyphase resampling but it still works very
well and I couldn't really hear any difference between the two. If someone
wants to generate real polyphase filter coefficients, they are welcome to
submit a patch.
- The IROM now contains the 4 mixing functions used by the AX UCode: mix_add,
mix_add_two, mix_add_ramp, mix_add_ramp_two. They are large, inlined
functions (probably for performance reasons) in the official DSP IROM, our
version prefers to use a loop. This *should* be more performant with our DSP
JIT implementation, but I did not benchmark that.
Because the new DSP ROM is working just as well as the official ROM in 95% of
cases, it is now shipped by default with Dolphin and will be used with DSPLLE
if you don't have an official DSP ROM in User/GC. It will still display a panic
alert at every boot to notice you that you are using a non official DSP ROM
made by us, which is not perfect.
Games using the CARD, IPL or GBA UCodes are still broken. I don't know what
games this actually impacts, but this is a very small proportion compared to
what works.