Project

General

Profile

Emulator Issues #6914

Sonic Unleashed along with many other games is not showing any 2D graphics.

Added by NeoBrainX about 7 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
Category:
GFX
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Current
Regression:
Yes
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Game Name?
Sonic Unleashed

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?
64 bit

Is there any other relevant information? (e.g. logs, screenshots,
configuration files)
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.


Related issues

Has duplicate Emulator - Emulator Issues #7048: Eternal Darkness Black Screen as soon as menu items appearDuplicate

Has duplicate Emulator - Emulator Issues #7379: F-Zero GX Cutscenes not being shown with OpenGLDuplicate

Has duplicate Emulator - Emulator Issues #7420: Eternal Darkness: Sanity's Requiem — Title Screen Not VisibleDuplicate

Has duplicate Emulator - Emulator Issues #7779: Sonic Colors 2D overlays invisible with D3DDuplicate

Has duplicate Emulator - Emulator Issues #7784: Sonic Colors - Invisible HUD in all backendsDuplicate

Has duplicate Emulator - Emulator Issues #7803: Sonic Colors no longer loads up HUDDuplicate

Has duplicate Emulator - Emulator Issues #7804: Sonic Colours not rendering text and title imageDuplicate

Has duplicate Emulator - Emulator Issues #7849: True Crime: Streets of LA menu is AWOLDuplicate

Has duplicate Emulator - Emulator Issues #7863: SONIC AND THE SECRET RINGS : Nothing is displayedDuplicate

History

#1 Updated by NeoBrainX about 7 years ago

Of course, I actually meant that revision 3aa0a63fe636 specifically was the commit which reverted the hack that made OpenGL work at all.

#2 Updated by kostamarino about 7 years ago

Actually it also affects sonic colours with opengl, similar issue with 2d elements not showing up.

#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.

#6 Updated by Xtreme2damax about 7 years ago

I think Sonic Colors is also affected by the same issue. Only with OpeGL, D3D works fine except for an ugly white box caused by a regression from another commit.

#7 Updated by a41pizza about 7 years ago

Is there a way to make a custom projection hack out of this, or is it something that can be put into the code for all time?

#8 Updated by NeoBrainX about 7 years ago

We don't want any new hacks, please stop suggesting anything like this because it's not the point of this report.

#9 Updated by a41pizza about 7 years ago

Sorry, could have been more sepcific. I was wondering how this was going to be fixed: if it's a global projectedPosition change that could be applied to all games, or if is something that needs to be game-specific in the code.

#10 Updated by pauldacheez about 7 years ago

It'll be a global change to how projectedPosition is calculated or used, nothing game-specific. This issue is meant to find out how to properly fix a bug that was previously fixed by a game-specific hack that neobrain removed.

#13 Updated by JMC4789 about 7 years ago

True Crime: Streets of LA is also affected by this

#15 Updated by JMC4789 about 7 years ago

F-Zero GX is also affected by this; kills videos.

#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[1], 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.

[1] http://fgiesen.wordpress.com/2011/07/05/a-trip-through-the-graphics-pipeline-2011-part-5/

#17 Updated by skidau about 7 years ago

issue 7048 has been merged into this issue.

#18 Updated by JMC4789 almost 7 years ago

  • Regression set to Yes
  • Milestone set to Current

Removing the Sonic Unleashed Hack has caused regressions, which should be a high priority to fix. Putting milestone current at least.

#19 Updated by skidau over 6 years ago

issue 7379 has been merged into this issue.

#20 Updated by kostamarino over 6 years ago

issue 7420 has been merged into this issue.

#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.

#24 Updated by kostamarino over 6 years ago

JMC while i don't have a problem reimplementing past projection hacks in the database i want the confirmation from others first that they are ok with it (so that i won't end up bothering about it for no reason).

#25 Updated by JMC4789 over 6 years ago

neobrain prefers just merging in something for a stable release, but never putting it into master. So, we're still in disagreement right now. I'll need a word from him, as he obviously overrides my opinions on the matter.

#26 Updated by kostamarino over 6 years ago

Now all backends are consistent having the same behavior after https://github.com/dolphin-emu/dolphin/pull/1346.

#27 Updated by kostamarino over 6 years ago

Due to the above i am changing the title.

#28 Updated by kostamarino over 6 years ago

issue 7779 has been merged into this issue.

#29 Updated by JMC4789 over 6 years ago

issue 7779 has been merged into this issue.

#30 Updated by JMC4789 over 6 years ago

  • Status changed from New to Fix pending

This should fix all issues with the Sonic Unleashed Hack. https://github.com/dolphin-emu/dolphin/pull/1366

#31 Updated by JMC4789 over 6 years ago

issue 7784 has been merged into this issue.

#32 Updated by pauldacheez over 6 years ago

issue 7803 has been merged into this issue.

#33 Updated by pauldacheez over 6 years ago

issue 7804 has been merged into this issue.

#34 Updated by spongecraft1212 over 6 years ago

Glad to know that other people are having the same exact issue.

#35 Updated by JMC4789 over 6 years ago

issue 7849 has been merged into this issue.

#36 Updated by zebralightningstudiosco over 6 years ago

Whoops, I searched for True Crime LA and didn't find a preexisting issue, sorry about that! :\

#37 Updated by JMC4789 over 6 years ago

issue 7863 has been merged into this issue.

#38 Updated by JMC4789 about 6 years ago

  • Status changed from Fix pending to Fixed

#39 Updated by MofoMan2000 about 6 years ago

This is still an issue with True Crime: Streets of LA as of 4.0-4669. That game might have a different issue.

#40 Updated by kostamarino about 6 years ago

Mofoman, with 4.0-4672 i can't see a problem, can you post a pic?

#41 Updated by MofoMan2000 about 6 years ago

http://www.mediafire.com/view/n5lrvh9w1bzcws3/WhurrIzMenu.png

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...

#42 Updated by JMC4789 about 6 years ago

Try EFB2RAM, right?

#43 Updated by MofoMan2000 about 6 years ago

But of course, I generally use EFB2RAM anyway. Real XFB makes the intro videos render, but doesn't fix the menu at all.

More information, my GPU is an NVidia GeForce GTX550Ti, driver version 347.09.

#44 Updated by JMC4789 about 6 years ago

That's weird. I wonder if this game has another issue.

Also available in: Atom PDF