http://bugs.winehq.org/show_bug.cgi?id=22366
Summary: Call of Duty 4 is black in-game Product: Wine Version: 1.1.42 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: wylda@volny.cz
This is 0-Day regression, which causes that Call of Duty 4 is completely black in the game. You see just amount of ammo but no 3D visual. Other things like menu, intro etc is OK. Reverting on top of wine-1.1.42-345-gd4b8536 makes this problem go away.
Hi Roderick, hopes that this get fixed before tomorrow's release ;) Otherwise i will spend next 14days wit confirming this commit as regression...
commit 10f58c14bcdeba9f7ea82701b9d9ab8f2bb3414b Author: Roderick Colenbrander thunderbird2k@gmail.com Date: Mon Apr 12 12:08:06 2010 +0200
wined3d: Improve FBO support in ClearSurface.
:040000 040000 9a3f2c11e17e5e98c8f5beadfd14a32dc04528a9 a2fdf8a6d92b60e289defed53374593da2cf4d83 M dlls
http://bugs.winehq.org/show_bug.cgi?id=22366
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |thunderbird2k@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=22366
--- Comment #1 from Roderick Colenbrander thunderbird2k@gmail.com 2010-04-15 15:38:13 --- Rico reported the bug to me as well and he reported that on ATI his system even crashes after a few seconds in game (I'm on ATI as well). Further I don't have the game and I'm not sure if the demo shows the same issue.
I will see what I can do but it is a bit hard to figure out without having the bug here. I have the feeling that some OpenGL states are getting messed up or so which other wined3d calls don't expect or so.
http://bugs.winehq.org/show_bug.cgi?id=22366
--- Comment #2 from Wylda wylda@volny.cz 2010-04-15 15:52:12 --- (In reply to comment #1)
...he reported that on ATI his system even crashes after a few seconds in game...
nVidia v195.36.15 here; i really test it just few sec, because i don't see nothing i do not wait for a crash ;)
...not sure if the demo shows the same issue.
Yes, demo is affected the same way.
I will see what I can do but it is a bit hard to figure out without having the bug here. I have the feeling that some OpenGL states are getting messed up or so which other wined3d calls don't expect or so.
If i could help somehow, just ask.
http://bugs.winehq.org/show_bug.cgi?id=22366
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #3 from Dan Kegel dank@kegel.com 2010-04-15 16:47:30 --- You could revert...
http://bugs.winehq.org/show_bug.cgi?id=22366
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mgavl69@juno.com
--- Comment #4 from Austin English austinenglish@gmail.com 2010-04-15 17:39:39 --- *** Bug 22367 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=22366
--- Comment #5 from Henri Verbeet hverbeet@gmail.com 2010-04-16 04:00:38 --- Created an attachment (id=27379) --> (http://bugs.winehq.org/attachment.cgi?id=27379) patch
Just a guess, does this patch make it any better?
http://bugs.winehq.org/show_bug.cgi?id=22366
--- Comment #6 from Henri Verbeet hverbeet@gmail.com 2010-04-16 04:24:09 --- Btw, please set the component to directx-d3d for Direct3D regressions, it makes them show up in my "D3D regressions" bugzilla list.
http://bugs.winehq.org/show_bug.cgi?id=22366
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Component|-unknown |directx-d3d Ever Confirmed|0 |1
--- Comment #7 from Vitaliy Margolen vitaliy@kievinfo.com 2010-04-16 08:35:24 --- And confirming.
http://bugs.winehq.org/show_bug.cgi?id=22366
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
http://bugs.winehq.org/show_bug.cgi?id=22366
--- Comment #8 from Austin English austinenglish@gmail.com 2010-04-16 11:56:24 --- Patch was committed here: http://source.winehq.org/git/wine.git/?a=commitdiff;h=738ca2f5fcf6e9deea4236...
http://bugs.winehq.org/show_bug.cgi?id=22366
--- Comment #9 from Rico kgbricola@web.de 2010-04-16 12:56:10 --- The mentioned commit fixed the problem.
(I have to make a small correction. I was using a nvidia 8800GTS when the crash happened after about 20 seconds.)
http://bugs.winehq.org/show_bug.cgi?id=22366
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #10 from Wylda wylda@volny.cz 2010-04-16 23:52:19 ---
Confirmig, FIXED in 1.1.43. This was pretty quick (_again_) Henri :))
I'm curious, how is it possible, that others don't need to see this bug. I already noticed that in bug 22083. So you write a piece of code, test it, but the application goes by different code path.
Is not meant as offend... I understand that bugs happens, just i'm surprised.
http://bugs.winehq.org/show_bug.cgi?id=22366
--- Comment #11 from Roderick Colenbrander thunderbird2k@gmail.com 2010-04-17 05:54:10 --- There are a lot of different codepaths in wined3d. You do test certain apps and run the wine d3d tests (and also extend them) but you don't always cover all situations.
The d3d test coverage should be improved to prevent more regressions. Writing tests can be boring though. When I rewrite a piece I try to add some tests. In this specific case I wrote one for the ColorFill behavior and didn't look too much at the Clear behavior (I expected the current test to be enough there). Especially for trickier areas, I'll try to write more tests when I touch such an area.
http://bugs.winehq.org/show_bug.cgi?id=22366
--- Comment #12 from Henri Verbeet hverbeet@gmail.com 2010-04-17 17:14:54 --- (In reply to comment #11)
There are a lot of different codepaths in wined3d. You do test certain apps and run the wine d3d tests (and also extend them) but you don't always cover all situations.
The d3d test coverage should be improved to prevent more regressions. Writing tests can be boring though. When I rewrite a piece I try to add some tests. In this specific case I wrote one for the ColorFill behavior and didn't look too much at the Clear behavior (I expected the current test to be enough there). Especially for trickier areas, I'll try to write more tests when I touch such an area.
More tests would be good of course, but you can hardly blame this one on the test coverage. I have the strong impression that this patch was created by simply copying around some code from color_fill_fbo() (compare the original http://www.winehq.org/pipermail/wine-patches/2010-April/087103.html with http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/device.c;h=91e5...), without much understanding of what the involved code does.
http://bugs.winehq.org/show_bug.cgi?id=22366
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #13 from Alexandre Julliard julliard@winehq.org 2010-05-07 13:30:17 --- Closing bugs fixed in 1.1.44.
-
wine-bugs＠winehq.org