Warped screenshots at horizontal resolutions not divisible by 32

[Aemony]

Description:
Recently it seems that capturing screenshots using Special K at horizontal resolutions not divisible by 32 creates warped screenshots in D3D9 and D3D12.

• OpenGL (both vanilla and IK) as well as D3D11 is not affected by the issue.
• It affects both 32-bit and 64-bit games as well.
• No error messages are logged in Special K's logs, nor is any indicator of an issue shown either beyond the warped result of the screenshot capture.
• This affects both the saved screenshot file on the drive as well as the clipboard that gets generated.
• As long as the horizontal resolution is divisible by 32 the issue won't occur regardless of the vertical resolution.

Steps to reproduce:

1. Launch a D3D12 or D3D9 game and configure it to run in a 1680x1050 window using the in-game settings screen.
   • Other common resolutions that triggers the issue are 1360x768, 1366x768, 3440x1440.
   • Do not rely on SK's overrides as those might affect the end result.
2. Restart the game to ensure there's no traces of the previous resolution remaining in the game session.
3. Wait until the main menu of the game has booted up.
4. Use F8 or F9 to capture a screenshot using Special K (or any other relevant hotkey).
5. Inspect the warped screenshot that's produced.

Affected APIs:

• D3D9
• D3D12

Unaffected APIs:

• D3D11
• OpenGL
• OpenGL-IK

Affected resolutions:
Any horizontal resolution not divisible by 32 seems to be affected by it.

• 1680x1050 (16:10)
• 1360x768, 1366x768 (16:9)
• 3440x1440 (21:9)
• 3240x2160 (3:2)
• etc

[Aemony]

The following example was produced using The Ascent with the game running at 2100x900 in a window in D3D12 mode. No other third-party software is involved in the game session -- Nvidia Ansel had been blocked and even Steam's overlayrenderer64.dll file was denied execution prior to launching the game.

Resulting screenshot:

Files:

• SpecialK.ini

Logs:

• dxgi_budget.log
• game_output.log
• modules.log
• SpecialK.log
• steam_api.log
• crash.log

[Aemony]

Correction: Any horizontal resolution not divisible by 32 seems to be affected by it, so it's not actually related to the aspect ratio itself.

[Kaldaien]

Problem is caused by drivers not including correct stride in resource description, it's unlikely this can be fixed.

[Aemony]

Dr. Dro was able to reproduce it on AMD hardware with a 1680x1050 resolution as well (1680%32 == 16, so not divisible by 32).

It sounds unlikely to be a driver issue affecting both vendors, but barring any other possible cause that does sound possible, unless maybe it's something in Windows itself that broke recently? 🤔

Edit: Lilium threw together some CPP code that's able to at least restore the partial corrupted data (though some data loss is unrecoverable):

• undoMess.zip

[EndlesslyFlowering]

here is a slightly updated version that now writes a line of black pixels instead of repeating the last useable line of pixels
also a few more comments to make it easier to understand
undoMess.zip

[Aemony]

I've gone back all the way to v 20.12.30 and confirmed the same issue exists even on that version with The Ascent running in a window at 1680x1050 resolution on my work PC... And that's like one of the first versions that had DirectX 12 support, I think?

My work PC uses Nvidia's Quadro drivers from May, v 512.78, along with last month's Windows 10 update, so those aspects are somewhat up-to-date as well...

The data would seem to suggest that this bug has been present for the longest of times, which I find baffling to the extreme -- do we really not have more users using e.g. 1680x1050 or 1360x768/1366x768 with Special K ? Those resolutions combined are used by like ~8% of Steam's userbase.

This sure is a doozy.

[mirh]

I'm going out on a limb and argue that the hardware of aficionados here is very much skewed towards the higher end (let alone if you consider that those reporting back are yet even a more exclusive club).
Also, even though SK is certainly a must for HDR screenshots, I'd still use steam or whatnot otherwise.

[Aemony]

I'm going out on a limb and argue that the hardware of aficionados here is very much skewed towards the higher end (let alone if you consider that those reporting back are yet even a more exclusive club).
Also, even though SK is certainly a must for HDR screenshots, I'd still use steam or whatnot otherwise.

Yeah, though as Special K by default hooks the Steam screenshot feature, it would create issues even for users using the standard Steam feature if it was combined with Special K... It's partially why I am so surprised we haven't heard of it before...

Anyway, since the issue have shown itself to be elusive it'll probably be a long while before it's fully tracked down and worked around, or solved if that's even possible.

[Kaldaien]

This should now be fixed, it was a combination of incorrect memory alignment (D3D9/D3D12 SDR) and SK accidentally invoking its own hooked function (D3D12 HDR).

There are some slight color processing differences that I am working out in DirectXTex. So I don't want to close this thread just yet -- screenshot code's still effectively broken in the sense that SDR screenshots have a slight blue shift versus the Steam overlay or ReShade doing the capture.

[marat569]

While DX9 is great, 22.7.19 does not work with DX12 SDR or HDR, while the version before it worked for SDR.

3440x1440

[ghost]

3440x1440 @ 175Hz, Steam overlay on.

As of 22.8.13:

DX9 SDR - broken, no screenshots are taken at all, no click from screenshot sound, nothing in folder. Portal 1 tested.
DX11 SDR - working, Garfield Kart Furious Racing tested.
DX11 SK HDR - working, INSIDE tested.
DX12 SDR - working, RE Village tested.
DX12 SK HDR - working, RE Village tested.

[Aemony]

D3D9 SDR should now work again.

[Aemony]

This was solved a year ago and the issue hasn't cropped up again.