Emulator

From my testing seems that with the new shader cache version Xenoblade needs the projection hack (-)+zNear to be activated (ticked without zNear correction).
In this way the day-sky is no more black and returns light blue.

fwiw, the sky seems fine for me in the latest master - r5b2c5c9ce37b Any chance you could try that? Also try manually deleting your shadercache files...

With r5b2c5c9ce37b Still black sky if I don't enable the projection hack.
Here WINDOWS XP SP3 32-bit, Ati Hd4850 Catalyst 11.5, Intel E8400, Dolphin 32-bit.

Eh, whatever... :p

Sorry to have blamed the new shader cache version because it's not guilty...the black sky comes with r3.0-79 (revision 8b8e60c2767d - in fact it comes with r3.0.77 http://www.emucr.com/2011/09/dolphin-git-30-77.html but I can't find the reference on the changes on master...where are them? Numbers got mad?); instead the sky is perfect with r3.0-71 (Revision c0dd84cf7d04).
Furthermore there's a DSI Exeption problem that affects these revision but I'll open another issue for that...

Ok, now I found out (these absurd revision numbers are driving me crazy), there were two revisions with the same description, so it is definitely as follows: light-blue sky on Revision c0dd84cf7d04 (3.0-71) and black sky on Revision 11933bf6b5fd (3.0-77).

btw things like git bisect make regression testing very easy: http://book.git-scm.com/5_finding_issues_-_git_bisect.html

still, this is either an amd or user issue...

Must be an XP issue because in issue 4926 hbk sais he has black sky using a nVidia Geforce GTX460.

..or 32bit issue ;)

These are the changes from r3.0-71 to r3.0-77 that may have caused the issue:

Dolphin Git changelog:

• disable ltcg for release build
• vs2010: Disable LTCG for realz
• Fix various cases in scissor rect emulation.
  Patch by delroth.
• apply to dx9 and dx11 backends as well
• Merge some scissor rect related code to VideoCommon.
• Merge branch 'scissoring-fixed'
  Fixes various cases in scissor rect emulation. This should fix glitches in various games, right now it's only known to (partially) fix Baten Kaitos: Eternal Wings.
  Fix by delroth, port to D3D9/11 by godisgovernment, cleanup by me.

Issue 4926 has been merged into this issue.

Is it possible to rename the issue "Xenoblade Chronicles black sky and DSI exception during intro cut-scene"? Thanks.

This issue never happened to me, and the last rev i checked was in v3.0-183.

sky and every single gfx in the game works fine and normal.
tough the game tends to crash time to time, but still... don't recon this gfx problem
not in d3d or openGL

maybe some incompatibility with the Graphic Card or an XP thing (I use 7 x64)

Tested it with my GTS 450
and my old pc wich has a GeForce 8400 gs 512
neither of them had the black sky thing, so yeap... user compatibility thing or XP problem

Could someone experiencing the issue please test r95517a9741175f15124dc11e132620a23bec7a19 and rb867c21fea6401c0f9886129621bb0dbae962a4a specifically? Thanks!

Please can someone post a build link on those revs? Thank you

No issues here, HD6650, Windows 7, 64-bit. Try using an OS that is not 10 years old and try again.

Can't reproduce either. HD6770, Linux x86_64, Catalyst 11.8.

have the same problem on ATI4870, WinXP SP3

Could this be related to the texture issue in Tales of Graces? http://code.google.com/p/dolphin-emu/issues/detail?id=2999

No, this problem showed up only with r3.0-77

To be precise - r3.0-77 and later but, as the devs said, it can be fixed by using the Custom Projection Hack -> (-)+ zNear in the game properties.
I tested the game on a friends PC with the following specs:
CPU: Intel Q6600
RAM: 4GB
GPU: ATI Radeon 3850
OS: Windows 7 Ultimate 32-bit
and got the DSI exception.

And the dark sky is also showing while running Xenoblade Chronicles on Win 7 32-bit.

Ok, so now we know for sure that the black sky and the DSI exception are a 32-bit issue.

That's what it looks like. My advice is - everyone who has this issue to use the Dolophin 3.0 version(no the git-s) untill the devs resolve the issue. And, I know it's offtopic, the OpenGL plugin in Kirby's Return to Dreamland is broken.

Can those with the black sky issue please test with the official 3.0 release?

As I wrote the issues (Black sky and DSI exception) start with r3.0-77; the official 3.0 isn't affected like every release until 3.0-71 included.

If we want to be more precise the unaffected versions are: the official 3.0 and every other until r.3.0.-76(new-shadercache-uids). r.3.0-76 is the last revision before the start of the black sky and dsi exception issues.

rbcb8d11c1b9f surely did NOT cause this issue. Clean your ShaderCache directory between different builds when testing that revision range.

Geez, what's wrong with people not doing reliable testing these days >_>

Also, those "3.0-76" numbers are useless, tell us the git hash in the future instead (from the about dialog).

I quote myself with the information that I've already written and that indicate exactly the information needed (the revision responsible is between r3.0-71 and r3.0-77 but unfortunately I couldn't find any build between them):

Ok, now I found out (these absurd revision numbers are driving me crazy), there were two revisions with the same description, so it is definitely as follows: light-blue sky on Revision c0dd84cf7d04 (3.0-71) and black sky on Revision 11933bf6b5fd (3.0-77).

These are the changes from r3.0-71 to r3.0-77 that may have caused the issue:

Dolphin Git changelog:

• disable ltcg for release build
• vs2010: Disable LTCG for realz
• Fix various cases in scissor rect emulation.
  Patch by delroth.
• apply to dx9 and dx11 backends as well
• Merge some scissor rect related code to VideoCommon.
• Merge branch 'scissoring-fixed'
  Fixes various cases in scissor rect emulation. This should fix glitches in various games, right now it's only known to (partially) fix Baten Kaitos: Eternal Wings.
  Fix by delroth, port to D3D9/11 by godisgovernment, cleanup by me.

Fwiw, does this happen with native IR, efb to ram, real XFB as well?

Yes, it happens with every possible video configuration...the only way to have back blue sky is to enable the projection hack (-)+zNear (ticked without zNear correction), but even with the projection hack the DSI exception is still happening.

OK...here are the builds which I wanted you to test before...

r95517a9741175f15124dc11e132620a23bec7a19 and b867c21fea6401c0f9886129621bb0dbae962a4a:
http://min.us/mbozDqCOc8#1

I tested r95517a9741175f15124dc11e132620a23bec7a19 and b867c21fea6401c0f9886129621bb0dbae962a4a and the game froze when you entered combat, more specifically when you use a skill after you have entered a battle. The projection hack((-)+zNear) was enabled.

This was the last revision where evyrithing worked perferct:
Revision: 34671140e09f308975a3c05bb3d48c157ea45c8f.
Branch: master

This commit (34671140e09f308975a3c05bb3d48c157ea45c8f) does not even exist...

I downloaded the file from http://forums.dolphin-emulator.com/showthread.php?tid=14356&pid=169677 and it's name was 3.0-71 Xenoblade HLE Hack v3.1 Win32.7z.

this topic is ONLY about the black sky issue, obviously...so do proper testing kthx.

OK, sorry. So to sum things up: the black sky appears in these two build and every build after them(that's what 32-bit OS users experienced).
As for the game freezing and the DSI exception also happening on 32-bit systems I think this was Issue 4926 and after it disappeared I thought it was merged with Issue 4906.

Thanks, I just tested r95517a9741175f15124dc11e132620a23bec7a19 (r3.0-73) and it's definitely this revision that causes black sky and DSI exception.

I'll keep the finger crossed, thank you.

Using r3.0-73 I was not able to get the DSI exception by playing Xenoblade's intro cutscene and doing 3-4 fights. Is there a reliable way to cause it or is it a random bug?

No, it's not random, it always compares at the same point of the intro, where Dunban comes out for the first time and faces against the Mechon. (on Ati HD4850, E8400 and WinXP 32-bit SP3).
With r3.0-73 r95517a9741175f15124dc11e132620a23bec7a19 you get the black sky or not?

@delroth: we already should be using fp:precise in the effected ppc files via #pragma.
This means it's in some other region of code. Would be cool to figure out which instead of unsetting fp:fast everywhere.