Emulator Issues #8898

WarioWare: Smooth Moves : 4.0-6204 breaks/hides certain objects with D3D.

Added by hosode almost 6 years ago. Updated almost 5 years ago.

% Done:


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


Game Name?
WarioWare: Smooth Moves

Game ID?

What's the problem? Describe what went wrong in few words.
Some 3d objects are not visible with D3D since Dolphin revision 4.0-6204. The same objects AND lots of other stuff got broken in 4.0-4446

What did you expect to happen instead?
All the objects to be visible.

What steps will reproduce the problem?
1. Use any Dolphin version since 4.0-6204. Set D3D backend (with fast depth on or off)
2. Start the game, play to the first stage, where you're being chased by a rolling rock.
3. At least two minichallenges are broken: the one where you shave (no razor visible) and the one where you try to hook the doll (only background visible).

Which versions of Dolphin did you test on?
Dolphin versions till 4.0-4441 work fine with D3D.
4.0-4446 (D3D: Replaced shader-based depth range remap with viewport (PR #1392 from kayru)) breaks lots of stuff (including these reported objects), but you get everything working if you set Fast Depth off with D3D. For example title screen shows only background texture.
Disabling fast depth does the trick up until 4.0-6192.
Then 4.0-6204 fixes a lot of stuff even with fast depth, BUT at least these two places are now broken with every setting I tried (fast depth, XFB virtual/off, EFB2tex/ram, dual core on/off, safe/fast texture).

Additional information:
4.0-6204 also broke Metroid prime depth effects and some other stuff, there is a yet-to-be-merged PR 2855 (see issue, I tested the provided test build but I does not fix the issue here.

What are your PC specifications?
Noticed this originally with: Win 8.1 64-bit, i5 4670S, Intel HD 4600 (latest drivers).
Verified and bisected: Win 10 64-bit, Intel Q9450, AMD Radeon 7850 (latest drivers).


#1 Updated by JMC4789 almost 6 years ago

  • Assignee set to Armada

#2 Updated by hosode over 5 years ago

There is another PR fixing depth related problems at GitHub, and since this issue still remains, I made two fifologs that show what the problem is. When viewed with D3D, there is the 3D-hooking-figure and the hook missing in the other one, and other log has no 3d-wiimote visible. Missing objects are properly showed when using OpenGL.

#3 Updated by JMC4789 over 5 years ago

It looks like this could be more related to Metroid Prime 2(Trilogy)'s issues. The good news?

The good news is that we found a bug in D3D11's way of handling depth. The bad news is that D3D11 may not be fixable without breaking other stuff.

#4 Updated by JMC4789 almost 5 years ago

  • Status changed from New to Fixed
  • Fixed in set to 5.0-440

This should be fixed now that D3D and OpenGL use the same equation for depth.

#5 Updated by hosode almost 5 years ago

As much as I'd love to confirm this being fixed, this is what happened:
-The razor, the hook and other polygon based objects that were previously hidden are visible. So in a way the issue is fixed, BUT:
-The background in the very same scenes is now black, which is a further regression. Other scenes seemed fine (had a very brief look at it), and the game still works as expected on OGL.

I know they are only 1 frame Fifo's above, but they show the same result compared to actual running game. I did not do any bisecting, compared with my in-use version 5.0-11, which has the earlier behaviour, so I can't swear that the black scene only appears at 5.0-440. I can check that later.

#6 Updated by hosode almost 5 years ago

So I tested 5.0-424 (the version before 5.0-440 "VideoCommon: Implement depth range equation in vertex shader."), and it has the old behaviour.
So there is still something weird going on with this game's depth, now it would seem logical to think that the background gets clipped somehow, while the objects are in correct order. Just guessing.

#7 Updated by JMC4789 almost 5 years ago

it should be fixed again in a new PR

#8 Updated by Armada almost 5 years ago

Actually it's fixed in this PR:

Please test it to confirm it's fixed and then I'll merge it:

#9 Updated by hosode almost 5 years ago

Tested PR 4140, and yes, I can confirm that it fixes all of the issues. Now I don't see any differences between OGL and D3D anymore.
Great job, again!

#10 Updated by JosJuice almost 5 years ago

  • Regression changed from No to Yes
  • Regression start set to 4.0-6204
  • Fixed in changed from 5.0-440 to 5.0-466

Also available in: Atom PDF