http://bugs.winehq.org/show_bug.cgi?id=58483 --- Comment #5 from Stefan Dösinger <stefan@codeweavers.com> --- I can reproduce this. It actually affects the initial loading screen already. As far as I can see the game creates a managed d3d9 texture and maps it with D3DLOCK_READONLY: 01a0:trace:d3d9:d3d9_device_CreateTexture iface 039CE8F8, width 2048, height 1024, levels 1, usage 0, format 0x35545844, pool 0x1, texture 0350F98C, shared_handle 00000000. ... 01a0:trace:d3d9:d3d9_device_CreateTexture Created texture 2BFC7960. 01a0:trace:d3d9:d3d9_texture_2d_LockRect iface 2BFC7960, level 0, locked_rect 0350F9B4, rect 00000000, flags 0x810. But it actually writes data into it. The copy is d3d9's doing, where it copies data from the sysmem wined3d texture into the default pool one. After the read-only lock the source texture has LOCATION_CLEARED | LOCATION_SYSMEM, and the code prior to commit 96fb128efd would pick up the sysmem copy, which happens to contain the data the game wrote. Now it propagates the CLEARED location, which is still considered valid because the game promised not to write any data. I vaguely remember similar issues in other situations. Maybe we should ignore the readonly flag on managed resources. Afair d3d<=9 managed resources can't ever be updated on the GPU side, so there's little use in a game really doing a read-only map. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.