D7VK v1.1 is out with experimental Direct3D 6 support via Vulkan for Windows games on Linux

The D7VK venture for offering Direct3D 7 assist on Linux with Wine / Proton has expanded within the model 1.1 launch so as to add experimental Direct3D 6 assist.

Like how DXVK began with the developer desirous to play NieR: Automata (see my original interview), the D7VK developer needed to play Sacrifice and Disciples II on high of DXVK and they also began D7VK to get them working nicely.

Within the now up to date readme file in for the 1.1 launch the GitHub the developer explains:

Wait, what? There is a D6VK in my D7VK! How did it get there?

After wanting over the D3D6 SDK documentation, it turned out to be considerably approachable, so I’ve carried out it. Help for D3D7 nonetheless stays the principle aim of the venture, however assist for D3D6 may also be offered, as an experimental addition. From a options and basic compatibility standpoint, count on it to fare considerably worse than D3D7, as a result of, as I’ve stated earlier than: the additional we stray from D3D8/9, the additional we stray from the divine.

Why not spin off a D6VK or rename the venture?

All APIs previous to D3D8 fall underneath the cursed umbrella of DDraw, so it makes completely no sense to separate issues up. As for any renaming, that will not occur, for the reason that venture’s primary focus stays unchanged.

Does that imply you may add assist for D3D5 and D3D3 in some unspecified time in the future?

No. However we absolutely assist D3D4 already, heh. Jokes apart, I’ve seemed over earlier API documentation as nicely, and I can confidently say that whereas D3D6 continues to be fairly just like D3D9, earlier APIs make use of a a lot, a lot cruder rendering pipeline that merely is not price mapping onto DXVK’s D3D9 backend. It additionally makes little or no sense to contemplate it, particularly given its complexity, since there’s little or no {hardware} acceleration to talk of earlier than D3D6 (and even in D3D6, if we’re to be trustworthy).

Different adjustments from the 1.1 launch embody:

Added a workaround for Sacrifice which permits the sport to correctly use 32-bit coloration / z-buffer depth. This can be a recognized drawback/limitation of the sport, which tries to make use of D32 for depth and falls again to 16-bit whether it is unavailable (D32 has all the time been usually unsupported, and is unsupported universally on fashionable drivers). The workaround vastly improves distant geometry rendering.

Added assist for strided primitive rendering, because of @CkNoSFeRaTU, which suggests Sacred is now playable.

Labored round lacking/swapped mip maps in Star Trek: DS9: The Fallen (#58), because of @esdrastarsis.

Added a workaround for Conquest: Frontier Wars, which permits the usage of D7VK for in-game rendering, assuming 3D acceleration and the specified decision are arrange beforehand. The sport depends on extremely cursed DDraw interoperability to work, so getting something out of it’s nothing wanting a miracle.

Fastened swapped mip maps in Gothic/Gothic 2 (#56).