Re: [PATCH v2 0/3] MR4781: ddraw: Make sure that sysmem surfaces remain coherent when not locked.
d2d9f713d forces us to create a separate wined3d_texture for texturing or RTV usage. I don't know why it was done this way instead of just continuing to allow CPU textures to be used as a texture/RTV; unfortunately neither the commit message nor the patches as submitted on wine-devel give any explanation. Even at that point the offending Emperor texture wasn't created with any bind flags. (Despite the fact that a color fill uses an RTV, it wasn't created with WINED3D_BIND_RENDER_TARGET; we don't currently validate that.) ee7d047dd55a forces all sysmem textures to get a draw texture. That means that the color fill acts on the draw texture instead of the sysmem texture, and the subsequent blits use ddraw_surface_get_any_texture() and hence pick the draw texture since that location is valid. It does slightly bother me that we're reimplementing all this logic on the client side, but I guess there was a reason for doing it this way... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4781#note_56702
participants (1)
-
Zebediah Figura (@zfigura)