Emulator

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

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

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)

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.

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.

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.

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?

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

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.

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.

True Crime: Streets of LA is also affected by this

Shrek 2 is also affected by this.

http://www.mediafire.com/download/zsbbz0n0194limd/ShrekFifos.7z

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

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 ([-2w,2w],[-2w,2w],[-2w,2w]) 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/

Issue 7048 has been merged into this issue.

Issue 7379 has been merged into this issue.

Issue 7420 has been merged into this issue.

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.

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.

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.

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

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.

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

Due to the above i am changing the title.

Issue 7779 has been merged into this issue.

Issue 7779 has been merged into this issue.

Issue 7784 has been merged into this issue.

Issue 7803 has been merged into this issue.

Issue 7804 has been merged into this issue.

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

Issue 7849 has been merged into this issue.

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

Issue 7863 has been merged into this issue.

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

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

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

Try EFB2RAM, right?

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.

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