**4/9**
Resident Evil 2 Classic (the one from GOG at least) comes with its own ddraw.dll wrapper on top of d3d9 which doesn't reject invalid FourCC formats for `DDSCAPS_OFFSCREENPLAIN` surfaces. It looks like the same is true for ddraw on Windows: nVidia rejects DXT* formats, allowing all the rest. AMD only rejects DXT* formats on `DDSCAPS_OFFSCREENPLAIN | DDSCAPS_SYSTEMMEMORY`, everything else is alright. FWIW with RE2 we end up trying to create an IV50 surface and things go quite wrong once that succeeds. I added a ddraw test for this.
Unfortunately I think this is not the right way to fix this, or at least, not the way native deals with this. If I use native quartz on builtin ddraw, and remove all formats from GetFourCCCodes(), it doesn't change which ones are accepted. YV12, UYVY, YUY2 are still accepted, as is NV12 (which we don't even return from GetFourCCCodes() in the first place). DXT1 is also accepted. IV50 isn't, but presumably would be if wined3d allowed it.
What *does* depend on GetFourCCCodes() is apparently ReceiveConnection(). So we should probably be filtering there instead. I'm guessing that'll solve your problem.
**5/9**
I think it has to do with current window / client coordinates not necessarily matching with reality with fullscreen d3d and especially ddraw, i.e. resizing the window while in fullscreen mode doesn't necessarily reflect on what appears on the screen. The ddraw clipper is "the ultimate authority" on the geometry that's supposed to actually end up on the screen; as I understand it, in practice the clipper is not affected by e.g. moving the window position while in fullscreen.
In the case of RE2, apparently the window rect doesn't exactly match the fullscreen rect, but also both `GetClientRect` and `ClientToScreen` are hooked by the included ddraw.dll, such that their results are mangled e.g. `GetClientRect` returns (-54,0)-(17,35), while the clip rect is the correct (0,0)-(320,240). I'm not sure if this is a good enough justification for the change though.
Oh, right, this is the bug where the game hooks a bunch of stuff. So do we expect that this change is a no-op in the absence of hooking?
If so, I'm willing to accept it—it may not be correct, but I have no idea how we'd figure out what is correct. We should add a comment though to specify why we're using a more verbose code path.
**6/9**
It doesn't look like RE2 calls that function, not sure if there are other ways to get there? I don't see `IVMRAspectRatioControl` being queried either. Hacking the vmr7 tests it seems to confirm that the default is to stretch (I guess you already knew this), but the game on Windows has the letterboxing. I'd be curious about the window dimensions on Windows, but I suspect that peeking into that is a step too far.
This is more of a problem though. I don't think we want to be changing the default AR mode. Is there a different path that we could be using to get the image onto the screen, one that might also be hooked by the native ddraw? [and that might also sidestep the GetClientRect() issue...]