From 5630cb5dc8ef7e9a8195262726f73d6828f59a6c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Stefan=20D=C3=B6singer?= Date: Fri, 17 Jan 2014 13:27:17 +0100 Subject: [PATCH] wined3d: Don't set SFLAG_DYNLOCK at surface creation. We no longer depend on SFLAG_DYNLOCK to create buffers and PIN_SYSMEM makes sure the address remains constant. --- dlls/wined3d/surface.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c index def47d3365a..87de9e1879d 100644 --- a/dlls/wined3d/surface.c +++ b/dlls/wined3d/surface.c @@ -6385,16 +6385,6 @@ static HRESULT surface_init(struct wined3d_surface *surface, struct wined3d_text if (lockable || desc->format == WINED3DFMT_D16_LOCKABLE) surface->resource.access_flags |= WINED3D_RESOURCE_ACCESS_CPU; - /* I'm not sure if this qualifies as a hack or as an optimization. It - * seems reasonable to assume that lockable render targets will get - * locked, so we might as well set SFLAG_DYNLOCK right at surface - * creation. However, the other reason we want to do this is that several - * ddraw applications access surface memory while the surface isn't - * mapped. The SFLAG_DYNLOCK behaviour of keeping SYSMEM around for - * future locks prevents these from crashing. */ - if (lockable && (desc->usage & WINED3DUSAGE_RENDERTARGET)) - surface->flags |= SFLAG_DYNLOCK; - surface->map_binding = WINED3D_LOCATION_SYSMEM; /* Call the private setup routine */