On Tue, Sep 19, 2006, Stefan Dösinger wrote:
Am Montag 18 September 2006 10:12 schrieb Christopher GAUTIER:
I've identified a bug in IWineD3DDeviceImpl_CopyRects. When CopyRects() is called to copy the source entirely into the destination surface, and that the sizes matches, a plain memcpy() is done. However, this assumes that the surfaces have the same pitch, and this is not always the case.
Welcome to Wine :-)
Hi Stefan,
IWineD3DDevice::CopyRects is a subset of IWineD3DSurface::BltFast(from DirectDraw), and I thought some time ago I sent a patch which makes CopyRects call BltFast. This patch apparently wasn't applied, and I did a google search for it and couldn't find it either. Looks like I moved it to /dev/null accidentally. We should call BltFast to avoid duplicating code. BltFast is also able to handle corner cases like bad rectangles.
Can you test the attached patch? I have no game which uses CopyRects, so I can't test my patch. This is just a quick per-msdn implementation.
I've tested it. It works fine, and has the nice advantage of factorizing code.
However, it has a bug that my naive patch does not have: with your patch, the game is missing a fade from white. The main menu is supposed to be white at the beginning, and then fade into its final colours. With your patch, everything remains #FFFFFF-white, until the last frame of the fading, then the menu appears normally.
I have noticed that if, in your patch, I replace the second call to IWineD3DSurface_BltFast(pDestinationSurface, 0, 0, pSourceSurface, NULL, DDBLTFAST_NOCOLORKEY); by a call to IWineGDISurfaceImpl_BltFast(), then the fading is ok.
Do you have any hint of where I should look at to understand what is causing this? I have played a bit with the GL calls, to no avail.
Apart from this point, I agree your patch is much better than mine, as it removes code redundancy, and is probably faster :)
Cheers, krys