http://bugs.winehq.org/show_bug.cgi?id=34480 --- Comment #7 from Stefan Dösinger <stefan(a)codeweavers.com> 2013-09-23 09:41:45 CDT --- Created attachment 46054 --> http://bugs.winehq.org/attachment.cgi?id=46054 Test case Wine supports compressed mipmaps smaller than the block size just fine. The problem here is that LoL writes past the end of the first mipmap (Usually 64x64 one), causing a memory corruption. By luck it only happens to do that with textures that have mipmap levels < 4x4. It gets away with the broken memory write on Windows because the texture is a D3DPOOL_MANAGED texture and Windows allocates the memory for all mipmaps as one block. Thus when it writes past the memory of level 0, it just writes to the memory of level 1, 2, 3, etc. On Wine it writes into memory owned by the heap manager. The proper fix to do is to fix LoL itself. The next best thing is to replicate Windows' memory allocation strategy. To do so, we have to move responsibility for allocating memory from the individual surfaces to the containing texture. The attached patch is a test that tests the memory allocation behavior of Windows. A quick and dirty workaround would be to allocate twice the amount of memory for each resource in wined3d_resource_allocate_sysmem(). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.