http://bugs.winehq.org/show_bug.cgi?id=18993
Summary: Shadows and selection circles z-fight in World of Warcraft Product: Wine Version: 1.1.23 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: trivial Priority: P3 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: eiffel56@gmail.com
The lowest-setting shadows and selection circles in World of Warcraft do z-fight with the ground. This is not a regression afaik, at least I haven't seen an other behaviour yet.
As I was testing if the patch attached to Bug #14174(http://bugs.winehq.org/show_bug.cgi?id=14174) causes problems in other games, I noticed that the same patch does almost fix the problem in World of Warcraft. I modified it a bit so it entirely fixes that z-fighting, but now it doesn't fix the bug mentioned in report #14174.
As I don't really understand why its causing that, someone with enough knowledge should investigate in it. I will attach the modified patch, allowing to render lowest-settings shadows and selection circles correctly.
http://bugs.winehq.org/show_bug.cgi?id=18993
--- Comment #1 from Lisa Denia eiffel56@gmail.com 2009-06-18 20:29:59 --- Created an attachment (id=21885) --> (http://bugs.winehq.org/attachment.cgi?id=21885) Workaround enabling correct rendering of selection circles and shadows in World of Warcraft
http://bugs.winehq.org/show_bug.cgi?id=18993
Dorek Biglari dbiglari@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dbiglari@gmail.com
--- Comment #2 from Dorek Biglari dbiglari@gmail.com 2009-12-25 03:11:01 --- The problem is due to the undocumented (or rather incorrectly documented) depthbias feature in direct3d. This site http://aras-p.info/blog/tags/d3d/ explains the differences between resolving z-fighting conflicts in direct3d and opengl. The place we need to apply the patch is in dlls/wined3d/state.c, in the state_depthbias function on the line with the call to glPolygonOffset. Basically, you need to make the number that d3d is sending to opengl larger. This works on my configuration (NVidia 6xxx, 24 bit depth buffer, which I think is pretty common):
static void state_depthbias(DWORD state, IWineD3DStateBlockImpl *stateblock, struct wined3d_context *context) { union { DWORD d; float f; } tmpvalue;
if(stateblock->renderState[WINED3DRS_SLOPESCALEDEPTHBIAS] || stateblock->renderState[WINED3DRS_DEPTHBIAS]) { tmpvalue.d = stateblock->renderState[WINED3DRS_SLOPESCALEDEPTHBIAS]; glEnable(GL_POLYGON_OFFSET_FILL); checkGLcall("glEnable(GL_POLYGON_OFFSET_FILL)"); glPolygonOffset(tmpvalue.f/(2.0*4.8e-7), (*((float*)&stateblock->renderState[WINED3DRS_DEPTHBIAS]))/(2.0*4.8e-7)); /* Changed to fix z-fighting in WoW */ checkGLcall("glPolygonOffset(...)"); } else { glDisable(GL_POLYGON_OFFSET_FILL); checkGLcall("glDisable(GL_POLYGON_OFFSET_FILL)"); } }
I don't know what the proper procedure is for submitting this, hopefully somebody will see it. I'm currently using it and it works great. It may need to be tweaked with a different number for 16 bit depth buffers. This is my first comment here as I usually have just been a wine user, and just decided to start getting into the code. Let me know if this works for anyone else.
http://bugs.winehq.org/show_bug.cgi?id=18993
--- Comment #3 from Vitaliy Margolen vitaliy@kievinfo.com 2009-12-26 11:49:21 --- (In reply to comment #2) http://wiki.winehq.org/SubmittingPatches
In short - use git, make a patch, send it to wine-patches@winehq.org
http://bugs.winehq.org/show_bug.cgi?id=18993
--- Comment #4 from Austin English austinenglish@gmail.com 2009-12-26 19:32:39 --- Sent it for you: http://www.winehq.org/pipermail/wine-patches/2009-December/083221.html
http://bugs.winehq.org/show_bug.cgi?id=18993
--- Comment #5 from Henri Verbeet hverbeet@gmail.com 2009-12-27 05:57:13 --- Created an attachment (id=25417) --> (http://bugs.winehq.org/attachment.cgi?id=25417) patch
(In reply to comment #2)
glPolygonOffset(tmpvalue.f/(2.0*4.8e-7),
(*((float*)&stateblock->renderState[WINED3DRS_DEPTHBIAS]))/(2.0*4.8e-7)); /* Changed to fix z-fighting in WoW */
That doesn't look right to me, how does the attached patch work?
http://bugs.winehq.org/show_bug.cgi?id=18993
--- Comment #6 from Dorek Biglari dbiglari@gmail.com 2009-12-30 02:11:22 --- It scales the depth bias value to be in the correct range. I know it works on my hardware, an NVidia 6xxx running World of Warcraft in with a 24 bit depth buffer, but I'd like to know if it works on all configurations, or if it helps other apps. The number I divided by I got from the website: http://aras-p.info/blog/2008/06/12/depth-bias-and-the-power-of-deceiving-you...
The author is discussing a cross platform app he's writing using OpenGL and Direct3d. The Direct3d users were complaining about zfighting. I'll quote the pertinent parts:
"How do you apply depth bias in OpenGL? Enable GL_POLYGON_OFFSET_FILL and set glPolygonOffset to something like -1, -1. This works.
How do you apply depth bias in Direct3D 9? Conceptually, you do the same. There are DEPTHBIAS and SLOPESCALEDEPTHBIAS render states that do just that. And so we did use them.
And people complained about funky results on Windows."
He then goes on to state that he thought it was because people were using terrible near/far planes, which is what I would think too. And I think thats probably why Lisa's patch also seems to correct the problem, because its messing with the projection. But the guy hits on an issue I have run into with Direct3D before, that is that the documentation on the depth bias is wrong.
Continuing to quote from him:
"First, depth bias documentation on Direct3D is wrong. Depth bias is not in 0..16 range, it is in 0..1 range which corresponds to entire range of depth buffer."
...
"So yeah, the proper multiplier for depth bias on Direct3D with 24 bit depth buffer should be not 1.0/65535.0, but something like 1.0/(2^24-1). Except that this value is really small, so something like 4.8e-7 should be used instead (see Lengyel’s GDC2007 talk). Oh, but for some reason it’s not really enough in practice, so something like 2.0*4.8e-7 should be used instead (tested so far on GeForce 8600, Radeon HD 3850, Radeon 9600, Intel 945, reference rasterizer). Oh, and the same value should be used even when a 16 bit depth buffer is used; using 1.0/65535.0 multiplier with 16 bit depth buffer produces way too large bias."
I've been running Wow and wine with this patch and it fixes the problem and I have not noticed any side effects. Out of curiosity, why do you think it looks incorrect, Henri? If I am wrong here I would like to know. I assume that you have seen the z-fighting that Lisa reported. Let me know your thoughts.
http://bugs.winehq.org/show_bug.cgi?id=18993
--- Comment #7 from Henri Verbeet hverbeet@gmail.com 2009-12-30 03:20:01 --- (In reply to comment #6)
I've been running Wow and wine with this patch and it fixes the problem and I have not noticed any side effects. Out of curiosity, why do you think it looks incorrect, Henri? If I am wrong here I would like to know. I assume that you have seen the z-fighting that Lisa reported. Let me know your thoughts.
It makes sense to scale the WINED3DRS_DEPTHBIAS value if the value is specified in normalized depth coordinates for D3D. However, WINED3DRS_SLOPESCALEDEPTHBIAS is a scaling factor for the depth slope, so I don't think it makes sense to scale that one.
My patch is almost the same as yours, but doesn't scale WINED3DRS_SLOPESCALEDEPTHBIAS. It also uses 1e6f instead of 9.6e7f for the WINED3DRS_DEPTHBIAS scaling factor, but I think that with the exact scaling factor being device and driver dependant that shouldn't make much of a difference. 9.6e7f corresponds with 1/2^20, I guess, but it's not an exact representation anyway.
http://bugs.winehq.org/show_bug.cgi?id=18993
--- Comment #8 from Dorek Biglari dbiglari@gmail.com 2009-12-30 06:45:29 --- Ah! Good point, Henri. I didn't know if scaling WINED3DRS_SLOPESCALEDEPTHBIAS was necessary or not. Also, as for the actual scaling value, that sounds good too. As long as whatever value used works in most circumstances, I think thats good. Thanks for pointing that out to me.
http://bugs.winehq.org/show_bug.cgi?id=18993
Thomas Venieris mot@freemail.gr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #9 from Thomas Venieris mot@freemail.gr 2010-01-01 11:27:28 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=18993
Thomas Venieris mot@freemail.gr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mot@freemail.gr
--- Comment #10 from Thomas Venieris mot@freemail.gr 2010-01-01 11:29:07 --- Just to confirm the problem on: Debian x86_64 testing, wine 1.1.35 (compiled from source). The patch posted here solves the problem for me.
Best regards,
http://bugs.winehq.org/show_bug.cgi?id=18993
--- Comment #11 from Henri Verbeet hverbeet@gmail.com 2010-01-04 13:37:01 --- Should be fixed by 2c0edb94e3da37a736b73f1a647bd3c9863f2608.
http://bugs.winehq.org/show_bug.cgi?id=18993
Jukka Tastula poltsy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |poltsy@gmail.com
--- Comment #12 from Jukka Tastula poltsy@gmail.com 2010-01-28 16:57:40 --- Target circles and also projected textures are looking good now.
http://bugs.winehq.org/show_bug.cgi?id=18993
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #13 from Dan Kegel dank@kegel.com 2010-03-07 00:46:34 --- Can we close this, then?
http://bugs.winehq.org/show_bug.cgi?id=18993
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #14 from Jerome Leclanche adys.wh@gmail.com 2010-05-13 05:44:59 --- (In reply to comment #13)
Can we close this, then?
Yes.
http://bugs.winehq.org/show_bug.cgi?id=18993
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #15 from Dmitry Timoshkov dmitry@codeweavers.com 2010-05-13 06:22:05 --- Reported fixed.
http://bugs.winehq.org/show_bug.cgi?id=18993
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #16 from Alexandre Julliard julliard@winehq.org 2010-05-21 14:39:24 --- Closing bugs fixed in 1.2-rc1.
http://bugs.winehq.org/show_bug.cgi?id=18993
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |2c0edb94e3da37a736b73f1a647 | |bd3c9863f2608 CC| |focht@gmx.net