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