Am 23.01.20 um 16:46 schrieb Paul Gofman:
I have only one immediate idea what could we try to tweak. Due to failure condition 1. maybe initializing the destination surface with some different colours will change anything? It is very unlikely to fix the thing but maybe can give some idea what the failure is about.
Zeroing the destination surface right after creating it seems to fix the problem. I guess the driver's bug is that it doesn't do that for DXT3 surfaces. I have to use lock + memset to init the surface, DDBLT_COLORFILL returns E_NOTIMPL on compressed surfaces. I vaguely remember writing a test for that once.
I'll send a patch that manually zeroes the destination surface. If you feel like extending the blit test to blit onto a non-zero destination (I guess that's expecially fun for the driver when you do sub-block blits) just tell Henri to ignore it.
An unrelated problem I've spotted is that lock.dwSize is never initialized. In my testing we luckily get away with that because a large value gets left behind on the stack, and larger sizes happen to be OK for the specific combination of ddraw7 sysmem texture. I'll send a patch for that too.