On Fri Nov 21 22:30:44 2025 +0000, Elizabeth Figura wrote:
Yeah, these aren't too complicated so I don't mind the large series. However:
- 1/9 could use tests; should be easy enough to plug into test_default_presenter_allocate().
- 2/9... wow, that's surprising; it allows BI_BITFIELDS but not 16- or
24-bit BI_RGB. Okay then.
- 3/9 is fine, just want to write that for reference I did check with
Helen and the NV11 card does report NV12.
- Why do we need 4/9? Shouldn't it fail CreateSurface()?
- 5/9 is probably fine, although as someone less familiar with how this
area works I'd appreciate an explanation of why the current code is wrong. It's not exactly easy to look up, anyway.
- 6/9 should presumably only be applied if the application has called
SetAspectRatioMode(VMR_ARMODE_LETTER_BOX). Has it? And if it has, we presumably need to also clear the rest of the surface to black.
- 8/9 would probably make more sense if you just fit it into the table,
with depth=16 and depth=24 entries.
Thumb up for everything I'm not mentioning.
**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.
**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.
**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.
I dropped the patch for the time being.