[Bug 32397] New: Call of Duty 4: Regression: Flickering of particle textures switching from normal to spritesheet appearance
http://bugs.winehq.org/show_bug.cgi?id=32397
Bug #: 32397 Summary: Call of Duty 4: Regression: Flickering of particle textures switching from normal to spritesheet appearance Product: Wine Version: 1.3.23 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: Elias.vds@gmail.com Classification: Unclassified
When I updated from wine 1.3.22 to 1.3.23, COD4 rendered particles faulty: the textures constantly switch from normal to spritesheet appearance. I'm running Linux 2.6.32.26-175.fc12.x86_64 (Fedora 12) with NVIDIA GTX470 gfx card using stable driver version 195.36.31. No winetricks. The bug is still present in the latest (1.5.19) devel version of wine.
So this is a regression. First I thought this was a duplicate of bug 27630, but I'm using an NVIDIA card and the bug persists in wine 1.5.19.
I located the patch that broke it : Merging the reverted patch in wine 1.5.19 solves the problem.
However I assume this disables the new GL_ARB_ code? Anyhow, my gfx card should be able to handle the latest GL extensions.
http://bugs.winehq.org/show_bug.cgi?id=32397
Elias Vanderstuyft Elias.vds@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |Elias.vds@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=32397
--- Comment #1 from Elias Vanderstuyft Elias.vds@gmail.com 2012-12-08 05:20:45 CST --- Sorry, I forgot to attach the patch that broke it:
commit 68b15bc5ffe6ddf5d08cbc13479eaf718ad5e39f Author: Stefan Dösinger stefan@codeweavers.com Date: Fri 17 Jun 2011 13:37:45 +0000 (15:37 +0200)
wined3d: Give GL_ARB_map_buffer_range another try.
http://bugs.winehq.org/show_bug.cgi?id=32397
Elias Vanderstuyft Elias.vds@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=32397
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |68b15bc5ffe6ddf5d08cbc13479 | |eaf718ad5e39f
--- Comment #2 from Henri Verbeet hverbeet@gmail.com 2012-12-08 07:25:10 CST --- This sounds like some variant of bug 27534, does StrictDrawOrdering help?
http://bugs.winehq.org/show_bug.cgi?id=32397
--- Comment #3 from Elias Vanderstuyft Elias.vds@gmail.com 2012-12-08 07:45:18 CST --- (In reply to comment #2)
This sounds like some variant of bug 27534, does StrictDrawOrdering help?
I can confirm that setting Direct3d/StrictDrawOrdering to 'enabled' solves the issue.
However does the performance increment of the usage of dynamic VBOs makes up for the performance decrement of StrictDrawOrdering? If not, then this issue should get more attention. (Please correct me if I'm wrong.)
http://bugs.winehq.org/show_bug.cgi?id=32397
--- Comment #4 from Elias Vanderstuyft Elias.vds@gmail.com 2012-12-08 07:53:55 CST --- (In reply to comment #3)
(In reply to comment #2)
This sounds like some variant of bug 27534, does StrictDrawOrdering help?
I can confirm that setting Direct3d/StrictDrawOrdering to 'enabled' solves the issue.
However does the performance increment of the usage of dynamic VBOs makes up for the performance decrement of StrictDrawOrdering? If not, then this issue should get more attention. (Please correct me if I'm wrong.)
The StrictDrawOrdering arrangement worked for wine 1.5.19.
But did not solve the issue for wine 1.3.23. Anyway I assume this is irrelevant.
http://bugs.winehq.org/show_bug.cgi?id=32397
Elias Vanderstuyft Elias.vds@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hverbeet@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=32397
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |DUPLICATE
--- Comment #5 from Stefan Dösinger stefan@codeweavers.com 2012-12-08 07:58:10 CST --- Looks like Bugzilla swallowed my earlier post.
(In reply to comment #3)
However does the performance increment of the usage of dynamic VBOs makes up for the performance decrement of StrictDrawOrdering? If not, then this issue should get more attention. (Please correct me if I'm wrong.)
No, it's not even close. For this game you're clearly better off by disabling dynamic VBOs, e.g. by commenting out the extension in the extension table at the top of dlls/wined3d/directx.c
The (presumed) proper solution is a worker thread that executes all the commands. That way we can do the ordering sychronisation ourselves with classic thread synchronization techniques rather than forcing opengl to do it for us by calling glFlush() after pretty much every operation. This is a complicated task and won't happen tomorrow however.
I don't intend to work on any hacks that attempt to improve this game's performance in the current way multithreading is handled.
(In reply to comment #4)
But did not solve the issue for wine 1.3.23. Anyway I assume this is irrelevant.
Yes, there was a bug that was fixed by 5d1d07abcf3deab4397a0008ae8c44493a721c6a.
*** This bug has been marked as a duplicate of bug 27534 ***
http://bugs.winehq.org/show_bug.cgi?id=32397
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Stefan Dösinger stefan@codeweavers.com 2012-12-08 08:02:26 CST --- Fyi, some other bug concerning performance and the lack of a worker thread is bug 11674.
I'm closing this one.
-
wine-bugs＠winehq.org