D7VK v2.2 for playing retro Windows games on Linux improves Direct3D 3 support
D7VK v2.2 is out now continuing to improve retro Windows games on Linux with improvements to Direct3D 3 and various bug fixes.
What exactly is it? Forked from DXVK, the idea is to provide accurate and perfomant Direct3D 7, 6, 5 and 3 to Vulkan translation to Linux for use with Wine / Proton to run Windows games.
Writing about the new release the developer said:
“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”.
They also go over a reminder on DXVK-Sarek 1.13.0 getting released and what improvements it brings, along with all these other fixes and additions noted below.
- 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.
🌐 External Sources: GitHub – d7vk – v2.2
Article taken from GamingOnLinux.com.
