Version 2.2

It's been a while since any major work was done on any particular API, in our extended family of olden D3D APIs, but ever since its addition in D7VK v1.5, D3D3 has definitely been the most neglected of the bunch.

Though all the D3D3 games I managed to collect and test worked fine with D7VK, the implementation definitely had its rough edges and unhandled corner cases, which could show signs of explosion in some yet unknown titles. This was particularly problematic, since D3D3 games are like the fabled "Palantír"s in The Lord of the Rings: artifacts lost to time and certainly not all accounted for. It's with v2.2 that D3D3 support has finally been brought in line with everything else. You know what they say: "better late than never".

DXVK-Sarek 1.13.0

A new release of DXVK-Sarek is also out, and it includes some major work done on the early D3D part of its codebase:

• All the added functionalities of D7VK v2.1 have been backported on top of Sarek, along with some changes done to streamline future backports. Expect one of this release rather soon 😉.
• D7VK's support for color key transparency has been reimplemented from scratch, written specifically for DXVK-Sarek's old compiler code, which has diverged dramatically from upstream DXVK, and thus couldn't benefit from a direct backport. This was done largely through the efforts of @CkNoSFeRaTU with Nvidia-specific bugfixing contributed by @pythonlover02. There's really no contest here in saying that color key transparency support is a MAJOR addition to Sarek, impacting a lot of early D3D titles.
• Similarly, Sarek has seen the addition of an albeit much simpler reimplementation of the alternate pixel center workaround for fixed function, which was needed to fix banding artifacts in Resident Evil 2.

Owners of older, only Vulkan 1.1/1.2 capable hardware, rejoice - you have not been forgotten. If we're to consider Resident Evil 2, and compare between Sarek 1.12.0 and 1.13.0, you'll immediately be able to see the impact of this recent work:

DXVK-Sarek 1.12.0	DXVK-Sarek 1.13.0

Fixes/additions:

• Rebased on top of the recent DXVK v3.1 release.
• Reworked the refcounting of D3D3 devices, ensuring it now behaves exactly like its native implementation.
• Correctly handled color keying enablement for pure D3D3 devices, expanding the very simplistic "always on" model we had thus far.
• Refactored D3D3 execute buffer validations and other corner cases with the help of Wine tests that were written specifically around D3D3 behavior (thanks to the kind soul(s) who spent their time writing them, centuries ago).
• Improved the robustness of texture handling for D3D5/3, by making sure the underlying surfaces won't go out of scope while in use.
• Fixed a D3D3 execute buffer transformation bug, which was caused by an invalid determination of the vertex input FVF.
• Fixed a bug with legacy projection matrix calculations, thanks to @CkNoSFeRaTU. It was spotted due to a failing Wine test, but could have had negative effects on (some) D3D6/5/3 applications.
• Improved the handling of normalized color range calculations for color keys, which are now only updated when the surface description is changed, thus being kept cached and optimized for reuse. The overall performance of color key transparency, in games which make use of it, is expected to improve slightly to moderately as a result.
• Fixed a regression caused by the above color key rework, wherein normalized color key range calculations could result in a division by 0 if applied on paletted surfaces. These types of surfaces are now ignored for D3D color keying in general.
• Refactored and improved the handling of the Begin() / Vertex() / End() D3D6/5 draw path, resulting in less memory overhead and slightly improved performance. This has had some positive impact on Frogger (1997).
• Fixed a corner case which allowed texture handle swaps on textures which hadn't been issued handles. This one's a valid, but mostly theoretical oversight, that hasn't been observed in the wild.
• Slightly improved the recently added read-only surface lock tracking logic, reducing its overhead.
• Removed the pessimization of legacy presentation paths, since they are equally needed and used by several older D3D titles.

Enjoy, and see you on the next one! Oh, and if you happen to recall and find any D3D3 titles to test with this release, or in general, that would be much appreciated. As I've mentioned before, they're rarities, and very poorly kept track of to begin with, even on dedicated sites such as PCGamingWiki.