Emulator Issues #6914
Sonic Unleashed along with many other games is not showing any 2D graphics.
What's the problem?
2D graphics don't show up in any of the mentioned renderers. That applies to the Wii screen at the very beginning but also to HUD elements ingame (which can be verified by going there via D3D and statesaving)
What did you expect to happen instead?
2D graphics should show up.
What steps will reproduce the problem?
1. Select the OpenGL or Software renderer
2. Run Sonic Unleashed
3. Notice how the 2D graphics (even the wrist wrap screen) won't show up even though the game runs fine
Alternatively, use the attached fifo log to debug the issue (see below).
Which versions of Dolphin did you test on?
4.0-575, aka revision 7a818e05ef3b .
Does using an older version of Dolphin solve your issue? If yes, which
versions of Dolphin used to work?
Revision 3aa0a63fe636 worked fine because it had a hack specifically with this game in mind. That only make graphics show up for OGL though, the software renderer was always broken.
Are you using the 32 or the 64 bit version of Dolphin?
Is there any other relevant information? (e.g. logs, screenshots,
I attached a fifo log which is supposed to show the wrist wrap screen. It works fine with D3D and on real hardware and thus can be used for debugging this issue.
#3 Updated by pierre about 7 years ago
For easy access, the problem as described in the comment reverted in revision 3aa0a63fe636:
Sonic Unleashed puts its final rendering at the near or far plane of the viewing frustrum(actually box, they use orthogonal projection for that), and we end up putting it just beyond, and the rendering gets clipped away. (The primitive gets dropped)
#4 Updated by NeoBrainX about 7 years ago
More specifically after playing around in the software renderer a bit, it looks like during clipping, projectedPosition.z + projectedPosition.w equals -0.0000001192092895507812500, which is smaller than 0 and thus fails the clipping test.
My guess is that screen coordinates aren't stored as floats but as fixed point values. This guess is based on an analogy to the PSP, which stores screen coordinates as 12.4 fixed point. A homebrew application should probably be written to figure out if the GC/Wii do a similar thing. Alternatively, maybe some patent texts have information about it.
#5 Updated by NeoBrainX about 7 years ago
Potentially interesting: If I let projectedPosition.z + projectedPosition.w equal to -0.0000001192092895507812500 (0xbc257f00) things show up correctly on my Wii, while a value of -0.0000002384185791015625000 (0xbc257f80) will break it even on the Wii.
At this stage I'm not sure if clipping is performed in low-precision floating-point coordinates or indeed in fixed-point math.
#14 Updated by JMC4789 about 7 years ago
Shrek 2 is also affected by this.
#16 Updated by NeoBrainX about 7 years ago
I'm now 99% sure that Flipper uses fixed-point values for screen coordinates (i.e. the Clipper output and input of perspective divide).
The software renderer currently doesn't use guard-band clipping, but really should. I.e. instead of clipping at z<=w, we need to perform it at z<=2*w. As suggested by a certain blog post, the output of guardband-clipping is usually stored in fixed-point integers. I have performed some very limited testing and found an upper bound of 21 fractional bits (I'll work on getting a more specific value).
I'd like to write some hardware tests for this, specifically the behavior of Flipper when clipping is disabled, yet the z=0 plane is crossed by a primitive. This is because I know that there is a guard-band clipping plane for the far-z case (presumably at z=2*w, surely not at z=w though), but as may be the case not for z=0.
For what it's worth, extending the clipping region from ([-w,w],[-w,w],[-w,w]) to ([-2*w,2*w],[-2*w,2*w],[-2*w,2*w]) and converting the resulting coordinates to a fixpoint s11.21 format resolves the Sonic Unleashed issue. This only covers the software renderer so far, of course. I'm not quite sure how to port such a fix to the HW renderers, yet. Probably needs the same frac() hacks that our tev emulation used to have until tev_fixes_new.
#21 Updated by NeoBrainX over 6 years ago
Given the time this issue has stayed unsolved now, I should point out that my statement in comment #17 is mostly invalid. This has nothing to do with fixed-point coordinate systems or anything like that.
However, it surely enough seems that floating point rounding errors before/during clipping play a role here.
#22 Updated by tueidj over 6 years ago
I don't know if you ever got around to testing what happens when a primitive passes through z=0 and clipping is disabled, but I can say from experience the result is not pretty and probably not something any sane game would do (the SDK documentation advises against it in several places).
There's a somewhat related hardware bug with very little documentation, when a primitive is near-clipped (passes through z=0) rasterized/vertex colour for the primitive gets screwed up; instead of interpolating between the clipped and non-clipped vertices, the colour values from the non-clipped get extrapolated.
#23 Updated by JMC4789 over 6 years ago
Something has to be done about this in the meantime. I know it's not a great solution, but perhaps we should implement some projection hacks in the INIs for the games afflicted. No one is probably going to fix this very soon, and at least with a bandaid (better one than before, even!) we could move this to mile-stone next.
#38 Updated by JMC4789 about 6 years ago
- Status changed from Fix pending to Fixed
Fixed by 4.0-4451 -> https://dolphin-emu.org/download/dev/bfc62d2adaf350cfb990c9de98039b48707c1347/ at least for now.
#41 Updated by MofoMan2000 about 6 years ago
Using 4.0-4889, OpenGL backend, highest accuracy settings enabled. Changing the settings makes no difference though, and it's even broken on the software backend.
Disk image info: True Crime: Streets of LA NTSC/USA (GTLE52). MD5 25a21ec4733cbfdec08f5f6e3f51454c
Should be perfectly fine, given that I dumped it from my own copy...