Emulator

Please try this with the Graphic_Fixes branch builds here:

http://code.google.com/p/dolphin-emu/source/detail?r=5650b3b5f6c4d915827768b6bb1f4f4c49982b21&name=Graphic_Fixes

@skidau: Yeah, I thought about that too, will try it later, now I just have to get outside, the sun is shining^^

Guess I have to delay testing a little bit more since my gamepad stopped working all of a sudden.

I dunno if I should post this here or at the other issue but:

Graphic_fixes builds have the same problem, so does a build of r7a17445. Will now try to find a build that works correctly.

Oh, I just realised OpenGL Renderer works fine.

Identifying which specific revision caused this issue will help us resolve it.

Could you provide a save state?

@hatarumo: Sure, here you go: http://dl.dropbox.com/u/35446621/GZLE01.s01

Btw I've just narrowed it down to somewhere between r25d1921 (or 3.0-95) and rb127b12 (or 3.0-137)

Since that revision range consist mainly of the new-shadercache-uids merge, I guess that's also the cause of this bug.

Try changing the "EnableShaderDebugging" variable in your gfx backend's config ini to "True". Emulation should be noticeably slower after that, but ideally will show an error message SOMEWHERE in the game (hopefully at least when the glitch shows up). Make sure to enable panic handlers.

Btw, this needs to be done in a radef86c1ef29da8b51dc3c0a3dc3c296d62e13aa build (or a newer one).

I tried and so far no error message appeared, not even in the Dragon Roost Dungeon but I only played like ten minutes since it really hurts my head playing at such a low framerate. Will try to play a little longer later today.

Well. just go to the place where the reported glitch occurs? :/

Yeah, I did, "Dragon Roost Dungeon"^^

Could you record 2 frames which show the issue via fifo recorder?

There you go:
http://dl.dropbox.com/u/35446621/ZeldaWW.dff

I recorded it with revision rec0ddb4

Post a memory card file save please.

Here:

http://dl.dropbox.com/u/35446621/MemoryCardA.USA.raw

Just go further inside till you come to the big room with lava.

Yes, last working revision for me is r3.0-97 Revision 175ade74d74d and then r3.0-135 Revision adef86c1ef29 is broken (I think there are no other revisions between them).
Unfortunately even setting "EnableShaderDebugging" variable to true I can't get any error message.

Not getting this issue at all. http://i.imgur.com/x8WCg.jpg

The heat effect is broken, but broken as it always was. Nothing new to see here for me.

Asus Laptop: K53TA
OS: Windows 7 Home Premium, 64-Bit - SP1
CPU: AMD Llano A6-3400M, Quad-Core, 2.4GHz
GPU: AMD Radeon HD6650, 1GB GDDR3
RAM: 4GB DDR3

Yeah, that's what the fifo log suggests as well. The issue report makes it sound like this is actually about a different issue, though?

This is what Staudi posted above:

Expected: Normal heat effect on walls in Dragon Roost dungeon
Actual output: Pulsating orange areas on the walls

http://i.imgur.com/IbXsV.png

The orange is what makes this a different case, afaik.

Yeah, but that wasn't visible in the fifo log.

It's about the walls, as tommy pointed out, not about the omnipresent heat effect. Normally there should be a slight orange glow to the walls, but instead there are very bright pulsating orange areas.

@tommyhl2: Did you use the OpenGl backend by any chance? Because it only occurs with dx9 and dx11.

Maybe a driver issue for you, and yeah, I was using DX9.

Strange, some other guy in the forums had the same issue, also a Nvidia GPU, and no notebook. I can see that you have a Radeon, so maybe it's a nvidia thing, for whatever reason.

It also happens if I start it using my Intel integrated GPU.

Here are two screenshots, so it's more obvious what I mean:

http://imgur.com/Qr53y

http://imgur.com/1Krmo

Dolphin probably won't use your Geforce GPU until you force it to through the Nvidia CP. Maybe your PC is using the Intel chip all the time.

I don't think it is a Nvidia issue, because I have an Ati Hd4850 with Catalyst 12.4 on WinXP 32-bit and have the same Dx9 plugin problem (orange walls and bridge).
OpenGL doesn't show the glitch.

@tommyhl2. Trust me, there's a very noticable decrease in speed when it's not using the Nvidia GPU^^

Staudi: Okay, just trying to eliminate some possible obvious reasons this could be happening. To me, seeing someone not have this issue at all, it points to something on your end being the problem.

Yeah, of course I didn't rule that out, I'm downloading new drivers for my GPU while I'm writing this (finally the vendor provided new ones) to see if that was the problem. It's just strange that e.g. 3.0 stable works perfectly, while the newer revisions have the problem and that some other guy in the forums encountered the same issue.

@tommyhl2: Could you post your settings, so I can try them out? Or did you try it on standard settings?

http://i.imgur.com/OqMur.jpg

Thank you, I just tried it, but I still have the orange walls. So it's not a matter of dolphin's settings. I have the newest DirectX and newest (available) drivers for my GPU. I would've suspected nvidia driver issues, but then hatarumo had the same problem with his AMD card. This is really strange, I have no idea where to look now.

Ok, just tried it on my old PC (Radeon X1600, Windows XP 32bit) and it doesn't have the problem.

Since apparently this is a regression of revision adef86c1ef29, it'd greatly help if anyone could find out which revision between 175ade74d74d and adef86c1ef29 broke this.

Until someone's willing to do this, I guess there's nothing I can do.

I would do it, but unfortunately I couldn't find any downloadable revisions between Revision 175ade74d74d (3.097) and Revision adef86c1ef29 (r3.135)

Get a copy of VS express and compile stuff yourself :D

As soon as I figure out this whole git fad I will try to narrow it down to one specific commit.

Okay, so I found out revision 08e06b22 is the culprit, I hope this can help to solve the problem.

I'm pretty sure, but just to be safe I'll check again.

Yup, checked again, it's revision 08e06b22

Awesome, thanks. Could you test if this https://dl.dropbox.com/u/10060691/0001-Fixing-stuff.patch patch fixes the issue?

Sadly that doesn't fix it, everything looks the same as before.

@neobrain: This patch fixes things for me, I just reverted part of responsible revision and picked the parts that seemed right (to me, and I can't code at all, so don't be suprised if it doesn't make any sense and breaks everything else^^), could you take a look at it, maybe it helps:

http://dl.dropbox.com/u/35446621/0001-Revert-Partially-revert-revision-d511b506120c.patch

Yo, I already found out what's wrong - just need some time to figure out how to fix it properly. I'd like to not have to reintroduce that ugly code again.

Ah, okay thanks for the update.

I just took a closer look at the affected code and while it would probably be possible to cleanup things properly, I'd rather have this issue fixed without risking any regressions atm, i.e. by reverting revision 08e06b22. Could you test that by applying the patch at http://pastie.org/4455890, this issue is still fixed on master?

@NeoBrainX: Sorry for the late answer but I was in Asia the last two weeks and didn't really have access to the internet. I will try it first thing tomorrow.

Sorry it took so long, but I had some computer troubles and then spent one week in Italy without my laptop so I couldn't test it. All that aside the patch still fixes the issue on newest master.

Awesome, thank you.

Oh yeah, as I suspected this also fixes the strange looking Octorok.