http://bugs.winehq.org/show_bug.cgi?id=14121
Summary: Max Payne Demo 1.05: rainbow texture artifacts on player model Product: Wine Version: 1.0.0 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: liquid.acid@gmx.net
Hi there,
I wanted to know if my system (Celeron M 1.5GHz, Intel i915 gfx chipset) was powerful enough to run Max Payne, so I tested version 1.05 (latest) of the demo on this system.
It works, but I encountered some visual errors. Looks like parts of the character textures become rainbow colored (see screenshots for more details).
This problem is not permanent. It's happening randomly and so I suspect this could also be a bug in the mesa i915 driver (so I'm filing a bugreport there too).
Thanks, Tobias
http://bugs.winehq.org/show_bug.cgi?id=14121
Tobias Jakobi liquid.acid@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jb.faq@gmx.de
http://bugs.winehq.org/show_bug.cgi?id=14121
--- Comment #1 from Tobias Jakobi liquid.acid@gmx.net 2008-06-25 10:20:42 --- Created an attachment (id=14354) --> (http://bugs.winehq.org/attachment.cgi?id=14354) Max how he should look like (reference)
http://bugs.winehq.org/show_bug.cgi?id=14121
--- Comment #2 from Tobias Jakobi liquid.acid@gmx.net 2008-06-25 10:21:05 --- Created an attachment (id=14355) --> (http://bugs.winehq.org/attachment.cgi?id=14355) Max with "rainbow" trousers (1)
http://bugs.winehq.org/show_bug.cgi?id=14121
--- Comment #3 from Tobias Jakobi liquid.acid@gmx.net 2008-06-25 10:21:33 --- Created an attachment (id=14356) --> (http://bugs.winehq.org/attachment.cgi?id=14356) Max with "rainbow" trousers (2)
http://bugs.winehq.org/show_bug.cgi?id=14121
--- Comment #4 from Tobias Jakobi liquid.acid@gmx.net 2008-06-25 10:22:42 --- Created an attachment (id=14357) --> (http://bugs.winehq.org/attachment.cgi?id=14357) Max with "rainbow" trousers (3)
I was very lucky to be able to capture this. Normally the rainbow effect disappears very quick (sort of flickers). Here it stayed very long.
http://bugs.winehq.org/show_bug.cgi?id=14121
Tobias Jakobi liquid.acid@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |http://www.3drealms.com/max/ | |downloads.html Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=14121
--- Comment #5 from Tobias Jakobi liquid.acid@gmx.net 2008-06-26 06:02:56 --- Created an attachment (id=14365) --> (http://bugs.winehq.org/attachment.cgi?id=14365) rainbow effect on all characters
Another screenshot where I managed to get the rainbow effect static.
Notice that the rainbow effect on the bad guy models is in-sync with the effect on Max trousers (and his gun).
Bad guys are affected everywhere by the effect (not only trousers like Max), while Max is only partially affected (trousers + gun).
http://bugs.winehq.org/show_bug.cgi?id=14121
Tobias Jakobi liquid.acid@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #6 from Tobias Jakobi liquid.acid@gmx.net 2008-09-02 19:52:47 --- I just checked the state of the bug with wine-1.1.3 and it was gone.
I did some reverse regression testing and this commit fixed it: 14b24058d69d73ebf6b70bc36c8aa62993351079 is first bad commit commit 14b24058d69d73ebf6b70bc36c8aa62993351079 Author: Stefan Dösinger stefan@codeweavers.com Date: Mon Jul 28 11:41:02 2008 -0500
wined3d: GL_ARB_fragment_program ffp implementation.
:040000 040000 7c5893f760a8534276c2e25f29a54edf26bd7887 5665d6fb1941d12140c2247a397c2ed254d11090 M dlls
However I doubt that the real problem was fixed, since after that commit the ARB_fp pipeline is used. There either is a problem with the pipeline that was used prior to the commit (maybe Stefan can comment on this?) or it's indeed a bug with the mesa driver.
Does someone have an idea? I'm not resolving this to fixed for now.
Greets, Tobias
http://bugs.winehq.org/show_bug.cgi?id=14121
--- Comment #7 from Tobias Jakobi liquid.acid@gmx.net 2008-09-06 20:22:40 --- OK, the bug still seems to be there.
New information I gathered with help from Henri Verbeet and Alexander Dorofeyev:
Alexander adviced to play around with the select_fragment_implementation code in directx.c - I stripped it down to always return ffp_fragment_pipeline and voila: the visual errors return.
So it's really a problem originating from using ffp_fragment_pipeline.
Henri Verbeet adviced to enable the frame dumping code in drawPrimitive (drawprim.c) and to match the trace with the backbuffer dumps.
While figuring out how to activate the code we also check the result with texture dumping. However it looks like the textures are not corrupted themself, but somehow wrongly applied.
I created a savegame from a spot where the problem can de reproduced every time. Tracing with +d3d,+d3d8,+d3d_draw and matching turned up this:
Subframe history: #2648: screen is cleared (cyan color) #2649: first geometry drawn on screen #2665: first visual error on screen (weapon model) #2669: last part of weapon model is drawn #2670: more correct geometry is drawn #2700: frame is finished #2701: screen is cleared again (cyan color)
Number of subframes used for full frame: 53 (2700 - 2648 + 1) Frame 17: weapon draw begins
Some tests reveal that at least from this ingame position it always takes these 53 subframes to complete a full frame and it's always frame 17 where the weapon is drawn. The weapon is also the very first geometry that has the textures wrongly applied.
I'm going to attach an excerpt of the trace that contains subframe #2649 to #2669. Like I already said the errors first appear with frame 2665. Maybe someone can figure out what is going wrong there. I'm still looking at the traces and I have began to comment it a bit, with what i think the calls are doing (I'm a d3d newbie, so I might be totally wrong here).
What someone could also test on a nvidia or ATI card: Patching select_fragment_implementation like I did and then also run a test. I'm going to upload my savegame so you don't have to search for a place where the bug appears.
Greets, Tobias
http://bugs.winehq.org/show_bug.cgi?id=14121
--- Comment #8 from Tobias Jakobi liquid.acid@gmx.net 2008-09-06 20:26:27 --- Created an attachment (id=15884) --> (http://bugs.winehq.org/attachment.cgi?id=15884) subframes #2649 to #2669
contains excerpt of the trace (+d3d,+d3d8,+d3d_draw)
http://bugs.winehq.org/show_bug.cgi?id=14121
--- Comment #9 from Tobias Jakobi liquid.acid@gmx.net 2008-09-06 20:28:05 --- Created an attachment (id=15885) --> (http://bugs.winehq.org/attachment.cgi?id=15885) savegame to use when checking the bug
http://bugs.winehq.org/show_bug.cgi?id=14121
--- Comment #10 from Tobias Jakobi liquid.acid@gmx.net 2008-09-18 19:32:59 --- Another update:
Previous tests were done using mesa-7.1 or older. With mesa-7.1 the texture corruption still is colorful.
However when switching to the Mesa software rasterizer the bug is gone. A strong indication that this bug is inside the Mesa i915 DRI driver.
So, mesa-7.2_rc1 came out some days ago. So I found it best to also test this pre-release. The bad news is: the bug is still there The good news is: the appearance changed, the textures that previously became colorful through the corruption are now completly white
What's also good: the changelog between 7.1 and 7.2_rc1 isn't that large, so it must be one of the few commits there that changed the behaviour.
Maybe I can bisect the commit, to get an idea what caused the change in appearance.
http://bugs.winehq.org/show_bug.cgi?id=14121
Tobias Jakobi liquid.acid@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID
--- Comment #11 from Tobias Jakobi liquid.acid@gmx.net 2008-09-21 11:51:46 --- Resolving this bug to INVALID.
Guillaume Melquiond is currently fixing this bug on the FDO bugtracker. A large part of the corruptions is already gone. This definitely is a bug inside mesa, but probably not only affecting the intel DRI driver. Maybe someone with a mesa DRI powered Radeon card wants to join the discussion on FDO? :)
URL to the FDO bugreport: http://bugs.freedesktop.org/show_bug.cgi?id=16520
Greets, Tobias
http://bugs.winehq.org/show_bug.cgi?id=14121
Tobias Jakobi liquid.acid@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Tobias Jakobi liquid.acid@gmx.net 2008-09-21 11:53:32 --- Closing, since discussion is now done at FDO (and the bug never really belonged here anyway).
And thanks to Henri Verbeet for the subframe debugging advice! :)