Emulator

Can you please stop discussing piracy and actually get on with this issue? I live in Switzerland and own the game, got it today in the mail, and dumped it to play on Dolphin in glorious 1080p, but the scan-lines on the background are awful. Strangely it works perfectly well on Rev. 7718, but the performance is much lower on that, with frame rates averaging 17 FPS on my rig, as opposed to 30 FPS at all times with 3.0.201. So if you have to know how to do it, please fix this issue asap.

Using this revision and these configs: http://www.neogaf.com/forum/showpost.php?p=32529372&postcount=5221

the game now looks like this: http://s5.postimage.org/x1krukj5z/ZSS2.jpg

However, I think the hand painted effect the game apply to far objects it's not perfectly emulated as you can see here.http://s5.postimage.org/iweysra4n/ZSS3.jpg

Maybe it's because the effect it's not prepared to work with high resolutions, is it possible?

By the way, I get stable 30FPS even with these high graphic settings. :D

Maybe it's because the effect it's not prepared to work with high resolutions, is it possible?

.. What about testing it with native internal resolution then? If it works with that, this issue is invalid.

What about testing it with native internal resolution then? If it works with that, this issue is invalid.

Here you are:
4xNative: http://img809.imageshack.us/img809/5513/zss3.jpg
Internal Resolution. http://img809.imageshack.us/img809/5395/zss4.jpg

I'm not sure if it solved or not. :P The game looks terrible using this resolution. Maybe someone playing it on a Wii can help us.

I think I prefer to play in HD even having the issue.

@neobrain: The issue is not existant in older revs, so it shouldn't have anything to do with the resolution. However, maybe the DoF effect is only (kinda) emulated in newer versions and maybe that's where the issue is.

Might be helpful if anyone actually bothered to find out in which rev it broke...

@marcel: What is the DoF effect? Thanks.

@neobrain: OK, I'll try to find it. I can't write code, so I want to help some way.

Fwiw, it was suggested that texcache-rewrite fixed this.
You might want to try Dolphin 7719 and 3.0-77 thus from http://www.dolphin-emulator.com/download.html?list=3 . If the latter doesn't work but the former does, it's highly likely that it's fixed by texcache-rewrite.

Yes the problem was definitely created between Dolphin 7719 and 3.0-77. When I use Dolphin 7719, the graphics look fine, but the game runs at about half speed. When I use 3.0-77, the graphics have a sort of interlacing problem. However, the game runs at full speed.

Dolphin 7719
http://i.imgur.com/Eio4a.jpg

Dolphin 3.0-77:
http://i.imgur.com/S7r1H.jpg

DoF = Depth of Field.
Yeah, texcache-rewrite would also have been my guess.

The game runs fine for me in OpenGL + r7719, and at normal speed too. I have unchecked the EFB RAM option, which might make the difference here. The config I'm using is the same as the one linked to in the forum thread, above.

I should add, however, that enabling anti-aliasing doesn't work for me in this particular build, I can't even get the title screen to show up. This is obviously a separate issue, but I just thought I'd include this info here for those reading that want to get their Zelda on.

You must have a past PC then, cuz OpenGL is the slowest for me in this game :/

Using r7719 i can play fine under Dx11 or opengl getting 30fps. Issues do appear in background as seen the the earlier screenshots

I have Dolphin Git v3.0-201 and I have also this problem.

It's interesting to notice that especially with the texcache rewrite version if you disable destination alpha pass the "colours tendency" change from green to a more accurate brown.

Everything after r7719 can render the Dof effect but needs EFB to Ram, which kills the Performance.
But r7719 is slower and has an green color stitch.

Afaik there is no solution to run this game 100% at this time.

@mueller :/ What feature is missing with these configuration? http://youtu.be/XDdqAHGq71o

I mean, that video doesn't show the game running perfectly? I'm playing with that configuration and I thought it was perfect. :(

Ok, you have the green stitch only in dx9 mode. Dx11 is ok.

@elias
In this configuration you miss the depth of field filter and you should have a strong computer.
Besides that everything should work fine.

Hey people, I hope this brings some light to somebody as it did to me:

1. First things first, update your GPU drivers. For me it was a good improvement.
2. Get r7719
3. Stick to http://youtu.be/XDdqAHGq71o config
4. Make sure you're using DX11
5. Don't use "Auto" for resolution, I use 2xNative
6. Uncheck "RAM" in "EFB Copies"

I finally got 30 FPS stable, background fixed and no greenish color. I'm 30 min on this game and I can say IT ROOOCKKKKSSS!

uhm, and you don't have the banding issue in the background, even with RAM unchecked?

Using r7719 is not a fix. There is no support for old revisions.

I tested this on a real Wii, and the 'distant stuff' on far objects which was presumed to still be an error, is not an error. It happens on the real Wii and this isn't a fact of it's lower resolution it can be clearly seen. This obviously doesn't apply to the backgrounds.

Nobody said the blur effect is an error.

Hi, I see that you all can use the Zelda, but I can't get pass the connect the Wii MotionPlus accessory, how do you bypass this screen to play?

@christop Use the forum for that kind of question. I have a Wii Motion plus.

I've read all the comments, and unless I overlooked something, no one stated this.

In the latest Dolphin build (Git v3.0-201) the only fix for this is to use DX11 and enable efb->ram, but it causes major framerate drops. It runs at about 25-27fps on an i5-2500k @4.6ghz with a geforce 280gtx. After pushing the i5 to 5.0ghz, it gets 30fps with processor usage at 97-100%.

ASRock P67 Extreme4
Intel i5-2500k @4.60GHz
4GB G.Skill DDR3 1600 (PC3-12800)
NVIDIA GeForce 280GTX 1GB

For those who need it ^{^}

I can confirm this is valid issue, something after r7719 has changed.

The problem is NOT with the blurred/painting-like background (this is by design - just DoF effect), but with jagged angled lines/bars on the textures and surrounding objects, as on the previously posted screenshoot:

http://s5.postimage.org/v34ey6ih3/ZSS.jpg

These angled lines are not present on r7719 (DoF is still there and works fine).

As mentioned, enabling efb->ram on the latest revisions fixes the problem, but totally kills the performance. r7719 works just fine without this 'hack', no glitches and performance is great.

I took some screenshots to help add detail to the nature of this issue. (They are spoiler-free, which I hope people respect as this is a new game)

It appears to be that the game's special effects are being rendered backwards. Perhaps backwards is not the right way to put it though; more appropriately, they are not being rendered in the correct direction. Compare the fence in the first and second screenshot:

http://img197.imageshack.us/img197/1885/soue011.png
http://img6.imageshack.us/img6/6236/soue012.png

And the next two screenshots, from first person view (where the effect seems drastically reduced), so you can see what the fence is supposed to look like. Note that it is still not completely correct (you can notice a white diagonal line through the fencing, seems to behave in the same way as the rest of the glitchiness). It does not get as bad as it does in third person, even if you step to an equivalent distance.

http://img829.imageshack.us/img829/9545/soue013.png
http://img213.imageshack.us/img213/7589/soue014.png

Finally, the effect seems to work based on slices of depth from the viewer, each individual slice of which seems to be rendered "backwards". See the pillars in the next two screenshots:

http://img163.imageshack.us/img163/2551/soue015.png
http://img528.imageshack.us/img528/9601/soue016.png

Not knowing a lot about 3D rendering technique this appears to me that it's probably an easy fix, as it's just something operating in the wrong order. It's also something that doesn't happen in the wrong order with EFB->RAM, even with texture caching enabled. Let me know if there is anything further I can do to help.

I also get this issue, I have a Radeon 6800 series. Perhaps people should share what video cards they are using. I saw a youtube video that that banding goes away for a person with a Nvidia card and setting the anisotropic filtering to 16x. i tried 16x but I still have the lines showing on textures. It does it for opengl and directx11+9... Using the ram option destroys performance and then there error is the texture/virtual setting, which is dependent on the video card. Driver issue? opengl and directx are just api's to the hardware level of the GPU. The other weird thing is I get banding if select "cached" on the RAM option of EFB, so not sure if its the video card

Try again with an r7623 build, please. Try both EFB to texture and EFB to RAM.

I just tried that, its the same thing. EFB to ram has no banding just like all the rest, but its horribly slow. The texture still had banding

Yeah, same issue here. EFB Copies to RAM fixes it but then even at minimum settings I can't get good FPS, understandable based on what this does. i7 2600K, GTX470.

I can confirm the 'banding/stripes' problem is there on r7623 - which is interesting, as allegedly only builds later than r7719 were supposed to be affected.

I have got Radeon 6850 card.

Builds after r7719 aren't the only one affected simply because the texcache rewrite was integrated with r7625 and reverted after r7719.

Would it be possible (not asking if you were willing to do it ;) ) to make it a special option, like a "game-fix"?

Is it really possible that something right does something so wrong and something wrong does something so right?

@marcel.w

Agreed, it would be nice to have the option selectable to work as a fix for this game.

Skyward Sword is the most important game for the Wii ever! Please fix!!

So as far as I understand, the proper emulation of this game requires 'EFB to Ram' (slower) mode and this works correctly in previous revisions only due to non-standard hack 'EFB to Texture' mode?

If there is no way to make the game faster in 'EFB to Ram' mode or render it correctly with 'EFB to Texture', could we please please have at least temporary hack that would allow Skyward Sword to work correctly in the current revisions?

my two cents, you can forget EFB to Ram unless you traveled from 2029 and brought your pc with you, "i come from the future and brought my pc, i'm terminator" (german accent)

@jpeterso...@gmail.com

Cool, so if EFB to Ram is not an option, is it normal that EFB to texture does not work correctly in this game?

If there is nothing wrong with EFB to texture implementation and this corruption is expected, do you think there is a chance to have hack for this particular game in place?

I'm all for hacks if you know me!, i advocate everything that makes a game better! I think the gameinis should have the optimal settings in them so we don't have to waste time on figuring that out. i've added control settings to the gameini in my clone, gonna add gfx settings too.

I remember your very creative, untypical and ultra-hackish Wind Waker music enabler tool! :) It allowed me to hear the music in this game for the first time in my life...
I am keeping my fingers crossed for hack/workaround for Skyward Sword (don't want to play it on my Wii, it just look hideous compared to Dolphin).

By the way, I am following Dolphin development from the very start and wanted to thank all the devs for all your hard work during these years. The fact that the latest and most powerful Wii game works straight away in Dolphin with hardly any problems is your huge triumph.

thx lukspica, thanks for your comment

Jpeterson, when you say control settings in the game ini, do you mean selectable control profiles( from the ones you make in dolphin) per game or do you have to manually edit the controls for each game in the ini file directly?

Anyway Copy to RAM works only with DX11, because with DX9 and OpenGL the background lines are still there.

Marking this as "wontfix" seems a little extreme to me. This isn't Barbie Horse Adventures, it's the Wii game of the year, and it's gonna get fixed at some point one way or another.

I think marking this "wontfix" and hiding it from the list of open issues is just going to cause more people to open duplicate issues, sort of like how there are about 58 issues for "WHY DOSE IT SAY YOU NEED MOTOINPLUS I HAVE A NES CONTORLLER I WATNED TO USE FIX IT NOW" open/closed every day.

If having the correct behavior (which apparently was part of texcache-rewrite?) breaks other games, then would it be possible to make a game-specific hack for it? If so, I think that's a good solution.

There's tons of reasons why we try to keep the number of hacks in the code at a minimum, and I (and others) keep repeating those reasons over and over again, so excuse my laziness in elaborating on this topic.

tl;dr is that if we'd add a hack for each "awesome game of the year", the Dolphin source would soon evolve into a huge unmaintainable mess (especially the gfx code, which is pretty wtf-ish already in many places anyway).

Ok, so instead of a game specific hack, what's the correct way to fix this so that Skyward Sword is emulated correctly? Because this is clearly an emulation bug.

At the very least, it might be nice if someone who understands what the bug is in EFB to Texture mode can explain it. That way perhaps a patch from someone not on the core team (that isn't a hack) could sort it out, even if core devs aren't interested in devoting time to it?

I don't think it's completely a matter of how good the game is, in my opinion it's more a matter of how important the "franchise" is...Nintendo has built his success mostly on Mario and Zelda, so not beeing able to properly emulate the last Zelda episode would be a let's say "stain" on what's instead a great emulator.
Btw I've always thought that this is the reason why Zelda Twilight Princess has it's own hack;-)

#1 "wontfix" is dumb. It's not like there's anything else coming out for the Wii at this point. What's out now is basically all you have to work with forever.

#2 If it's about accuracy, Zelda on Wii doesn't have giant candy cane diagonal scan lines plaguing the picture

Zelda on 7719 doesn't have giant candy cane diagonal scan lines plaguing the picture

Zelda in the new revisions does have giant candy cane diagonal scan lines plaguing the picture

Therefor 7719 is more accurate. And does it better to boot. It's not rocket science.

Fix this up so jpetersons motion+ work isn't marred by stupid lines and NeoBrains ego and so you don't hear about this for the rest of eternity.

I'm also not sure this should be "wontfix", I mean pretty much anything should be able to fix one way or another. Only because some devs might not be interested in fixing it, doesn't mean there might be others now or later who'd like to fix it, but if the issue is not there...?
I mean, there's a lot of issues which might never see a fix. But why hide them?

Assuming that the texcache-rewrite revert caused this issue:
a) ZTP only has a game specific hack because it was a small bunch of about 30 lines of non-fragmented and well separated code with VERY good documentation.
b) It'd be nice if the discussion could be focused on actual information which is related to this issue again rather than me debating with users about code quality.
c) it's not an emulation issue. EFB to texture itself is just a hack which is known to break games. Read what I said above about texcache-rewrite introducing other hacks on top of the EFB to texture hack (yayz!) to make it work anyway, probably causing all other kinds of weird regressions.
d) Any issue which gets fixed by enabling EFB to RAM is very likely an issue with EFB to texture for a good reason and not an emulation bug. No offense, but calling post-7719 builds inaccurate because something's broken with EFB to texture is kinda naive. If you knew how EFB to texture/RAM work in detail, you'd realize that (yes, even concerning this issue).

That said, I've got some hints from [SS] that this issue might not be fixed by texcache-rewrite at all but rather is a regression from the scissoring-fixed branch merge. However, I can't test this myself and no one else seems capable of testing the GIT revision before the scissoring-fixed branch merge. Until anyone can prove for sure that this issue was caused by scissoring-fixed rather than by the texcache-rewrite revert, I'll leave this issue closed. This is also the reason why I'm not further looking into this issue by the way, it's pointless to waste hours trying to find mistakes in commit X if the actual culprit is commit Y.

Scissoring-fixed was merged with Revision 11933bf6b5fd (3.0-77) and has nothing to do with this issue, it "only" probably broke Xenoblade Chronicles on 32-bit builds, but it is not guilty for this one.
I can say it because testing with the previous revision available Revision c0dd84cf7d04 (3.0-71) the background lines are still there (anyway it was already said that r7623 has the lines while r7625-texcache merge doesn't have them).

Alright, thanks for clarifying that.

Another question: why copy to RAM with DX11 fixes the problem, while in DX9 and OpenGL doesn't? Is it in DX11 more accurate and consequently a bit slower?

Ugh. I didn't even know about that until now. It's kinda hard to get all the relevant info (and not forget about it) if 90% of the comments in this issue are wrong or unrelated.

So... I take it that in D3D9 and OpenGL there is no way to fix this issue at the moment?

Yes ,in addition with those backends and efb to ram you get worse issues than with efb to texture...Do you want to post a picture?

I trust those who say that with DX11 copy to RAM is fixed (I'm using WinXP so I cannot test it myself), anyway with DX9 and OpenGL I tried every possible video option but I couldn't fix it (obviously this refers to non-texcache rewrite builds)

Dolphin v3.0

Dx11 Ram
http://i.imgur.com/5tY0Z.jpg

Dx11 Texture
http://i.imgur.com/d0X8V.jpg

While dx11 ram is better, it is not nearly as good as texcache-rewrite builds.
If you look at the ram picture, the pillar on the left has lines on it that shouldn't be there.

I also get the diagonal banding in the background with today's master (29f52ce6dd8b16773b48936cda80d434143966f1) on linux/opengl when "EFB Copies" is set to Texture. When I merge texcache-rewrite and rebuild, the problem goes away (the 'RAM' option in "EFB Copies" in unchecked).

Dolphin 204-dirt with texcache merged

Dx11 Texture:
http://i.imgur.com/xXl7w.jpg

Dx11 Ram:
http://i.imgur.com/ZNYEk.jpg

The target area is the left most side of the pillar, on non-texcache builds, its very jagged, where on the texcache ram its smoothed circles.

Forgot to mention, that I compiled with sse4.2 optimization enabled.

I opened issue: http://code.google.com/p/dolphin-emu/issues/detail?id=5056

May be a duplicate of this, I just hoped to give more detail on the problem.

This issue was closed by revision 3d9c35f58e84.

This issue was closed by revision 3d9c35f58e84.

This issue was closed by revision 3d9c35f58e84.