http://bugs.winehq.org/show_bug.cgi?id=28428
Summary: eXperience 112: broken shadows Product: Wine Version: 1.3.23 Platform: x86 URL: http://www.fileplanet.com/184348/180000/fileinfo/eXper ience112-Demo OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: gyebro69@gmail.com CC: stefan@codeweavers.com Regression SHA1: 68b15bc5ffe6ddf5d08cbc13479eaf718ad5e39f
Created an attachment (id=36445) --> (http://bugs.winehq.org/attachment.cgi?id=36445) screenshot
Shadows are broken (seem to be fragmented) in the eXperience 112 game.
Terminal output doesn't reveal too much: ... fixme:d3d9:Direct3DShaderValidatorCreate9 stub fixme:d3d:wined3d_buffer_preload Too many declaration changes or converting dynamic buffer, stopping converting fixme:d3d:state_zfunc D3DCMP_NOTEQUAL and D3DCMP_EQUAL do not work correctly yet. ... fixme:d3d:resource_check_usage Unhandled usage flags 0x8 ...
Shadows appeared correctly in 1.3.22. The result of the regression test:
68b15bc5ffe6ddf5d08cbc13479eaf718ad5e39f is the first bad commit commit 68b15bc5ffe6ddf5d08cbc13479eaf718ad5e39f Author: Stefan Dösinger stefan@codeweavers.com Date: Tue Apr 19 21:24:26 2011 +0200
wined3d: Give GL_ARB_map_buffer_range another try.
Nvidia's 270.xx.yy driver series fix the glMapBuffer alignment issues that caused major performance problems. If the user is using an older driver we now drop the VBO instead of using doublebuffered loading, which means that we fall back to the current behavior(no dynamic VBO) as needed. Dynamic VBOs are needed on Nvidia drivers for GL_ARB_instanced_arrays.
:040000 040000 0cada15043b731febf2ef2a673aaaecc4af75f8d c474ade74a8db2a9c547674dbb4c809841087a3d M dlls
Other bugs related to this commit: bug #27534, bug #27600, bug #27959. This might be a dupe of any of those.
As for performance issues due to this commit, I don't see major performance degradation, just because this game always performed badly on my system, when one or more cameras were activated in the game (5-6 fps @1024x768 resolution).
Steps to reproduce the problem in the demo: Install...launch...new game..skip the intro video...the problem can be observed right in the opening sequences.
Nvidia 250 / driver 280.13
http://bugs.winehq.org/show_bug.cgi?id=28428
GyB gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression
http://bugs.winehq.org/show_bug.cgi?id=28428
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
--- Comment #1 from Stefan Dösinger stefandoesinger@gmx.at 2011-09-18 17:19:36 CDT --- Does enabling strict draw ordering like in bug 27534 help?
http://bugs.winehq.org/show_bug.cgi?id=28428
--- Comment #2 from GyB gyebro69@gmail.com 2011-09-18 21:12:20 CDT --- (In reply to comment #1)
Does enabling strict draw ordering like in bug 27534 help?
No, it doesn't change anything.
http://bugs.winehq.org/show_bug.cgi?id=28428
sacrediou sacrediou@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sacrediou@yahoo.fr
http://bugs.winehq.org/show_bug.cgi?id=28428
--- Comment #3 from sacrediou sacrediou@yahoo.fr 2011-09-27 15:01:01 CDT --- Same problem here, using following system : - wine 1.3.29 64bit (clean prefix using playonlinux) - ubuntu 11.04 - radeon hd 6950 (fglrx 11.8) - amd phenom x6 1090T - "experience 112" FR (DVD version 1.0)
Default wine rendering options (glsl, direct draw renderer, video memory size, offscreen rendering mode, render target mode lock, multisampling, strict draw ordering).
App is running fullscreen. Only shadows are broken, everything else seems fine (video, 3d, blur effect). Rendering speed is good, even in 1920x1200.
With "strict draw ordering" enabled, shadows are still broken, and performance is awful.
Note : using wine 1.3.22, shadows are broken too, and the game is slow.
http://bugs.winehq.org/show_bug.cgi?id=28428
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru 2011-09-28 03:55:46 CDT --- (In reply to comment #3)
Same problem here, using following system :
- wine 1.3.29 64bit (clean prefix using playonlinux)
"clean prefix using playonlinux" is an oxymoron. Use plain WineHQ builld of Wine.
http://bugs.winehq.org/show_bug.cgi?id=28428
bugtracker@yopmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bugtracker@yopmail.com
--- Comment #5 from bugtracker@yopmail.com 2011-09-29 13:12:20 CDT --- What's(In reply to comment #4)
(In reply to comment #3)
Same problem here, using following system :
- wine 1.3.29 64bit (clean prefix using playonlinux)
"clean prefix using playonlinux" is an oxymoron. Use plain WineHQ builld of Wine.
What's wrong with playonlinux prefixes? The manual installation process just run two commands : wineboot and wine /path/to/file.exe. It uses system wine version. I don't see why it's an oxymoron.
http://bugs.winehq.org/show_bug.cgi?id=28428
--- Comment #6 from sacrediou sacrediou@yahoo.fr 2011-09-29 14:44:49 CDT --- (In reply to comment #5)
What's(In reply to comment #4)
(In reply to comment #3)
Same problem here, using following system :
- wine 1.3.29 64bit (clean prefix using playonlinux)
"clean prefix using playonlinux" is an oxymoron. Use plain WineHQ builld of Wine.
What's wrong with playonlinux prefixes? The manual installation process just run two commands : wineboot and wine /path/to/file.exe. It uses system wine version. I don't see why it's an oxymoron.
I think Dmitry was talking about games with playonlinux tweaks (lib overriding and stuff).
But experience 112 is not in playonlinux repository. So I made a manual empty/clean prefix with wine 1.3.29 provided by playonlinux. Maybe it's better explained this way.
I use this method very often to test games with different wine versions (and make them cohabit together...).
Nevertheless, I understood that it's not the same as plain WineHQ compiled from sources or a package provided by distro repository.
To be sure, I added official WineHQ ubuntu ppa (http://www.winehq.org/download/ubuntu) and tried with a new WINEPREFIX. The result is the same (it's like the screenshot provided by GyB).
http://bugs.winehq.org/show_bug.cgi?id=28428
--- Comment #7 from Stefan Dösinger stefan@codeweavers.com 2011-10-15 11:37:45 CDT --- I can reproduce this issue with the demo. A few notes for myself:
*) When disabling ARB_map_buffer_range but enabling dynamic buffers the bug goes away *) There's no multithreading involved *) The game uses only dynamic vertex buffers, no dynamic index buffers *) Rebinding the stream sources every draw does not help *) GL_MAP_INVALIDATE_BUFFER_BIT causes the issue *) No double maps(lock_count is never > 1)
http://bugs.winehq.org/show_bug.cgi?id=28428
--- Comment #8 from Stefan Dösinger stefan@codeweavers.com 2011-10-16 08:12:18 CDT --- Created attachment 36933 --> http://bugs.winehq.org/attachment.cgi?id=36933 wined3d: Clear unflushed buffer areas after a DISCARD map
The game is misbehaving. It is changing buffer areas outside the mapped area and depends on those changes to be uploaded to the GPU.
This hack reproduces the issue without any VBOs, dynamic or otherwise. It clears the area in the buffer behind the mapped area if the map used D3DLOCK_DISCARD. The game doesn't use offsets != 0 or double maps, so there are some shortcuts in that hack.
Likewise, if I flush the entire buffer, and not just the modified area, after a DISCARD map the shadows work correctly.
The open question is, why does the game get away with this on Windows? I could imagine that there's a driver hack. It's also possible that Windows drivers always flush the entire buffer, or flush on page boundaries.
http://bugs.winehq.org/show_bug.cgi?id=28428
--- Comment #9 from Stefan Dösinger stefan@codeweavers.com 2011-10-16 09:17:40 CDT --- Created attachment 36934 --> http://bugs.winehq.org/attachment.cgi?id=36934 wined3d: Mark the entire buffer dirty in a DISCARD map
This patch works around the bug by ignoring the range parameters provided by the app and assuming the entire buffer is mapped instead.
http://bugs.winehq.org/show_bug.cgi?id=28428
--- Comment #10 from GyB gyebro69@gmail.com 2011-10-16 11:04:42 CDT --- (In reply to comment #9)
Created attachment 36934 [details] wined3d: Mark the entire buffer dirty in a DISCARD map
This patch works around the bug by ignoring the range parameters provided by the app and assuming the entire buffer is mapped instead.
Shadows look good here as well with your patch.
http://bugs.winehq.org/show_bug.cgi?id=28428
--- Comment #11 from GyB gyebro69@gmail.com 2012-05-02 14:02:45 CDT --- Still present as of wine-1.5.3-73-g93a0ca7. Nvidia blob 295.40.
http://bugs.winehq.org/show_bug.cgi?id=28428
GyB gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |0610d1eec9a287e22831a40427e | |6a9a38f3f745f Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #12 from GyB gyebro69@gmail.com 2012-07-14 22:42:52 CDT --- Shadows in the game look good since Wine 1.5.7.
Fixed by http://source.winehq.org/git/wine.git/commitdiff/0610d1eec9a287e22831a40427e...
Nvidia 250 / driver 295.59
http://bugs.winehq.org/show_bug.cgi?id=28428
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #13 from Alexandre Julliard julliard@winehq.org 2012-07-17 13:52:27 CDT --- Closing bugs fixed in 1.5.9.
-
wine-bugs＠winehq.org