Emulator Issues #4989
Skyward Sword, background lines
1)Game: The Legend of Zelda Skyward Sword
2) What do you see?
Everything works fine except the background.
3) Did the game ever work correctly (i.e. not have this problem) on an
earlier version of dolphin?
I can't find a configuration that solves the problem.
4) What steps will reproduce the problem?
5) What version of dolphin are you using (32bit/64bit along with the
version as it appears in the title bar, etc)?
Dolphin 3.0 199-dirty 64bit
Intel i7 @2.80
6) Please provide any additional information below.
I've used the config posted by a user in the Dolphin forums. http://seemypic.net/images/normal/7935/dolphcfg.jpg
7) Attachments. I've made a screenshot of the issue: http://s5.postimage.org/v34ey6ih3/ZSS.jpg
#1 Updated by linkfx almost 9 years ago
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.
#2 Updated by eliaspoveda almost 9 years ago
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
#4 Updated by eliaspoveda almost 9 years ago
What about testing it with native internal resolution then? If it works with that, this issue is invalid.
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.
#8 Updated by NeoBrainX almost 9 years ago
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.
#9 Updated by bdr9 almost 9 years ago
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.
#12 Updated by joeauty almost 9 years ago
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.
#20 Updated by jordibalfa almost 9 years ago
Hey people, I hope this brings some light to somebody as it did to me:
- First things first, update your GPU drivers. For me it was a good improvement.
- Get r7719
- Stick to http://youtu.be/XDdqAHGq71o config
- Make sure you're using DX11
- Don't use "Auto" for resolution, I use 2xNative
- 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!
#23 Updated by linkandzelda2010 almost 9 years ago
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.
#27 Updated by eodeth almost 9 years ago
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 ^
#28 Updated by lukspica almost 9 years ago
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:
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.
#29 Updated by bastos.eder almost 9 years ago
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:
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.
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:
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.
#30 Updated by umarok almost 9 years ago
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
#36 Updated by NeoBrainX almost 9 years ago
- Status changed from New to Won't fix
Oh well, bad news I guess.
I haven't looked in detail into it, but this probably is "fixed" in tcr because of a certain hack related to EFB texture copies (replacing the first few bytes of the destination RAM area with a canary to check if the EFB copy contents have been written to).
This behavior likely won't get applied to master because it's just plain wrong though and will cause all kinds of other weird issues. I say "likely won't get applied" because I certainly won't do it and anyone else is unlikely to care or know wtf I'm even talking about.
#40 Updated by lukspica almost 9 years ago
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?
#42 Updated by lukspica almost 9 years ago
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?
#43 Updated by jpeterson57 almost 9 years ago
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.
#44 Updated by lukspica almost 9 years ago
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.
#48 Updated by bastos.eder almost 9 years ago
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.
#49 Updated by NeoBrainX almost 9 years ago
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).
#50 Updated by unit0x03 almost 9 years ago
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?
#51 Updated by hatarumoroboshi almost 9 years ago
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;-)
#52 Updated by ebenezergrymm almost 9 years ago
#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.
#53 Updated by marcel.werner3 almost 9 years ago
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?
#54 Updated by NeoBrainX almost 9 years ago
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.
#55 Updated by hatarumoroboshi almost 9 years ago
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).
#58 Updated by NeoBrainX almost 9 years ago
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?
#61 Updated by Anonymous almost 9 years ago
#62 Updated by NeoBrainX almost 9 years ago
- Status changed from Won't fix to Accepted
I'm not sure I see what you mean, the first screenshot looks fine to me. It just is low-res (which is expected with EFB to RAM) and hast some aliasing artifacts, unless I'm missing something. What about some comparision screenshots with the tcr build? (ONLY enable RAM and not virtual there).
Anyway, since apparently this issue does happen with D3D9 and OpenGL even with EFB to RAM enabled, I'll reopen it.
#63 Updated by kamm.christian almost 9 years ago
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).
#64 Updated by Anonymous almost 9 years ago
#66 Updated by nop_jne almost 9 years ago
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.