https://bugs.winehq.org/show_bug.cgi?id=12964
--- Comment #143 from Furyhunter furyhunter600@gmail.com --- The problem isn't an anti-hack issue. I have limited knowledge of direct3d, but I looked closely at the UnlockRect crash and it seems PSOBB 1.25.10-13 improperly LockRect a surface held by a texture immediately after calling LockRect on the texture itself. It then fails to UnlockRect the surface before UnlockRecting the texture, which seems to be poorly formed and results in a resource handling error in the wined3d implementation.
PSOBB seems to hold on to and reuse textures and surfaces throughout runtime, so the same texture interface struct is reused a lot.
The 1.25 patch was only released in Japan and included some undisclosed performance improvements. This might be why 1.24 gets past the bursting screen, but not 1.25.
The call order consistently looks like this:
tex.LockRect(NULL rect) surf.LockRect(NULL rect) // implicitly locks entire surface due to NULL tex.UnlockRect() // there is a missing UnlockRect on the surface? *CRASH* the surface interface struct return by get sub resource inside tex.UnlockRect causes a page fault. Exact line: https://github.com/wine-mirror/wine/blob/9bd963065b1fb7b445d010897d5f84967ea...
Presumably the intended order of operations is to include a surf.UnlockRect before tex.UnlockRect. But Windows may implicitly unlock the surface lock rects, though it is undocumented behavior.
I need more information to verify if the surface is actually a subresource of the texture, but if that is the case, then somehow the d3d8_surface impl struct retrieved by wined3d_resource_get_parent has an invalid pointer to the interface struct for the surface. It would not explain why Texture LockRect succeeds, because it gets the same information for locking. My gut says surface LockRect is breaking this somehow.
I will investigate this further because it may be a very simple fix.