Version 2.3

Although the codebase has reached what I'd call a point of maturity (also see the announcement below), this release rolls out several important reworks in terms of object handling as well as several new fixes and workarounds intended for early D3D games.

There is also one (perhaps final) performance optimization I was able to pull off, by controlling the memory placement of our shadow surfaces. These are mirror surfaces we create on the "legacy" presentation path to swap in for the actual primary surface, in order to prevent swap chain infighting caused by presents on the DDraw (WineD3D) swap chain.

They are fairly abused by games who are in the habit of blitting their cursor on top of the final rendered image, and as such we can see a rather nice performance improvement if we keep these shadow surfaces in system memory. Ironically, it's in Empire Earth where this difference is most noticeable, so although it already had its spotlight moment part of the v2.1 release, it makes a second appearance now, this time in a comparative benchmark and timeline evolution of D7VK performance:

Empire Earth - D7VK v2.3	Empire Earth - D7VK v2.2

Empire Earth - D7VK v2.0	Empire Earth - WineD3D (OpenGL)

Fixes/additions:

• Rebased on top of the recent DXVK v3.1.1 minor release.
• Streamlined shadow surface creation and tweaked its placement for a performance boost in most scenarios. This will typically lower the overhead seen in games that blit a cursor directly on top of the primary surface. Star Trek: Armada is the only known title that is hit by a performance regression because of it, so there's now also a config option to keep shadow surfaces in sync with the primary surfaces, as placed by the calling application. Worry not, you can still get the best Star Trek: Armada experience with D7VK.
• Added checks for Vulkan-side support of depth formats before reporting them as available. This might help sort out issues on various mobile platforms with limited format support.
• Added a workaround to fix intro video playback in the original (unpatched) release of Need for Speed: Porsche, by simply not providing support for overlay surfaces (thanks to @CkNoSFeRaTU for noticing this quirk).
• Handled interrupted/partial EnumSurfaces calls more robustly, preventing any surface leaks from the DDraw callbacks.
• Thanks to @CkNoSFeRaTU, we've worked around unspecified dwVertexCount values used during execute buffer setup, which fixes rendering issues in Dark Vengeance. As a result the game is (finally) playable on Linux.
• Relaxed RT surface validations for early D3D APIs, to reflect native behavior, which allowed for plain surfaces to be used as render targets.
• Added a ProcessVerticesStrided implementation for D3D7, although there are no known users at the moment.
• Updated extents during D3DPROCESSVERTICES_COPY execute buffer operations as well, as seen to be required by a few D3D3 games, such as G-Police and HyperBlade. The rework has also somewhat simplified the CPU ProcessVertices implementation, though it's unlikely there will be any noticeable performance differences.
• Consolidated texture handle logic across all early D3D APIs. This was necessary because D3D6, although touting to do away with texture handles, ended up having a fallback path which included, you guessed it, texture handles. This doesn't fix any problems per se, but is generally more robust against games who abuse the feature, such as Grandia II.
• Fixed a bug that caused stale alpha operations to remain in effect after the blend mode changed without any changes to the set texture. Thanks to @CkNoSFeRaTU for spotting it. This has fixed an issue with broken water surface transparency in Z.A.R..
• Unified the backend implementations for materials and textures across D3D6/5/3, wherever possible, by leveraging the already existing common objects.
• Unified the implementation of the D3D6/5/3 viewport, by implementing all interfaces with a single object. Sadly, it's only possible to pull off for viewports, since all viewport interfaces are extensions of one another, a singular case in early D3D. This has fixed crashing on game start with the (patched) GOG release of Star Wars: X-Wing Alliance and is generally more robust against mods/patches which hook the viewport vtable and rely on such implementation details.
• Removed some validations on execute buffer description struct sizes, because apparently they're not performed by the native implementation and some games are known to send junk sizes (cough, Forsaken, cough).
• Added an option to use an inverted LOD bias scale for mip mapping. This is apparently expected by some early D3D games, such as Redline Racer, due to a misleading D3D6/5 documentation entry.

D7VK is hereby entering maintenance mode. What does that mean?

• The codebase is considered mature enough to have met its initial... well, rather ever extending goals... of providing good support for all early immediate mode D3D APIs.
• No new major features are expected to be worked on in the future, though bug fixes and minor additions will trickle in, as usual.
• The release cycle will be a lot more spread out, with less frequent releases.

Should you run across any (yet unknown) bugs, please do raise an issue on our tracker. Otherwise, enjoy your time in the somewhat janky world of early D3D!