https://bugs.winehq.org/show_bug.cgi?id=52684
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #7 from Zebediah Figura z.figura12@gmail.com --- (In reply to bender647 from comment #5)
I'm guessing you did NOT run the game when prompted by the installer, and instead ran it afterward manually (and it failed to run). I was able to recreate this scenario a few times.
I'm pretty sure I did run the game when prompted, and it crashed the same way. Regardless, creating the Options.ini file as instructed did fix the crash, and allowed me to reproduce the bug.
This one actually turned out into a whole mess of related problems. The basic problem is that the game creates a SYSMEM and a DEFAULT texture, maps the SYSMEM with D3DLOCK_NO_DIRTY_UPDATE, then does IDirect3DDevice8::CopyRects() to copy it into the DEFAULT texture. There is one bug and two missed optimizations here, any one of which would be sufficient to avoid this:
(1) Normally the sysmem texture would be left in WINED3D_LOCATION_SYSMEM after the map, but because of the flag, we don't invalidate ~map_binding, hence CLEARED is valid. Based on some testing I believe this code path is incorrect, although I'm not sure it was possible to trigger an actual bug before the offending commit. Unfortunately we rely on that lack of invalidation in some other places, so those will also need to be fixed. In particular I believe we should be respecting the dirty regions for managed textures in wined3d_texture_load_location(), not when mapping. Even for managed textures SYSMEM should still be valid; it's just not uploaded to the GPU.
(2) In order to blit from a CPU texture in SYSMEM to a GPU-only texture in CLEARED, we end up loading the former into TEXTURE_RGB and doing a GPU-side blit. That should be avoided. We don't want to load the GPU texture into a CPU location, but we should be able to upload directly from the sysmem. Normally we do, but in this case texture2d_blt() thinks that since CLEARED is CPU accessible that this is a job for the CPU blitter.
(3) When loading a texture into TEXTURE_RGB whose valid locations are SYSMEM and CLEARED, we end up clearing the texture again, which can be avoided (if both of those locations really were valid, then SYSMEM is already cleared). This may not be worth optimizing, though, since it'd take some really weird usage to get here after fixing (1). [You'd have to do something like create a staging texture, map it read-only without initializing it, and then copy from it.]