Version 1.7.1

v1.7.1 is a quick "hotfix" release, bringing you the latest improvements in upstream DXVK. Most notably, users with AMD GPUs can finally enjoy their FSAA emulation in games making use of 16-bit color back buffers, as radv's 16-bit format texel buffer limitation has been worked around.

This means that if you're on AMD, you can stop using the ddraw.emulateFSAA = Disabled workaround and actually enjoy FSAA emulation in games that support it (or force it on even in games that don't, though be mindful of potential breakage). For Nvidia and Intel GPU users, it's all business as usual and this release doesn't do much, since there was no breakage to begin with.

For more details, see #120.

DXVK-Sarek v1.12.0

Meanwhile, DXVK-Sarek has seen a new release, which backports most D7VK functionalities onto its aging, yet non Vulkan 1.3 requiring, 1.10.x DXVK backend.

As I've mentioned before, this is good news for anyone stuck on a Nvidia Kepler card or an older Intel iGPU, however note that due to limitations inherent in its codebase, several D7VK features are unavailable within DXVK-Sarek, namely:

• Support for color key transparency
• Game controllable FSAA states (only force enabling FSAA emulation is possible)
• Conservative FPS limiter triggering
• Above mentioned 16-bit texel buffer limitations on AMD cards/radv remain in effect, though this is less critical due to the second bullet point in this list

The bottom line is that if you're in a situation where you have a Vulkan 1.3 capable GPU, so you can use D7VK, that will always remain the better choice, due to our tracking of the upstream codebase, and our rolling patch-set model, which gradually brings in the latest features and improvements from DXVK. That being said, we will also try to backport as much as we can to DXVK-Sarek, whenever that is possible without bumping backend requirements or causing general havoc/regressions.

Version 1.7

If you were to think there are some aspects of the D3D API which have remained mostly unchanged since early D3D up to D3D9, then you'd be right. It was this very fact that has allowed our rather steady progress of older and older API adoption. However, not everything played along. One area of clear divergence we've started digging into, and is now a featured part of v1.7, are legacy (D3D6 and earlier) vertex transformations, clipping and lighting.

The previously dark planets and units in O.R.B: Off-World Resource Base are now beautifully lit. Other games making use of legacy fixed function lighting aren't that "lucky" and still need some further work, so we're not all the way there yet.

On the sidelines, after some tinkering in the realm of games which have been broken for quite some time on Linux/Wine (as always, with the help of @CkNoSFeRaTU), we've found the means/workarounds to make some titles playable, such as Requiem: Avenging Angel and Warhammer: Dark Omen.

O.R.B: Off-World Resource Base	Requiem: Avenging Angel

Fixes/additions:

• Implemented legacy fixed function light attenuation for D3D6 and earlier.
• Thanks to @CkNoSFeRaTU, viewport transformations, clipping as well as D3D3 execute buffer transforms are also implemented, with a few remaining features to be ironed out in the future. This means quite a few early D3D3 and later titles are now in a somewhat playable state, for example Resident Evil, Revenant, Forsaken and many others.
• Worked around an iClassFactory initialization quirk to make Requiem: Avenging Angel happy, to the point where it starts up properly instead of complaining about missing D3D support.
• Thanks to @CkNoSFeRaTU, implemented a blit-instead-of-flip presentation workaround which happens to be very useful for handling the particularly odd way Warhammer: Dark Omen goes about setting up its presentation swapchain. It will now play back intros and gameplay just fine, instead of only a black screen. Note that the game is still affected by several Wine surface blit bugs, which cause missing/flipped menu elements.
• Vastly improved the reference counting situation, which may ultimately help with Windows compatibility. Mind you, Windows is still an unofficially supported platform that gets absolutely no testing with D7VK, so your mileage may vary.
• Fixed an oversight which prevented proper video memory reporting on GPUs with less than 2GB of VRAM and some iGPUs.
• Added a minimal ComputeSphereVisibility implementation, enough to get Space Empires V going (thanks to @Duneathor).
• Fixed a D3D6 viewport clear problem which affected sky color in Need For Speed III: Hot Pursuit (with the modern patch), thanks again to @CkNoSFeRaTU's investigative skills.
• Fixed several obscure device teardown issues which caused crashes on game exit in Incoming.
• Fixed missing 2D backgrounds in Return to Krondor.
• Reworked D7VK's D3D9 backend modifications in order to play nicely with the existing D3D8/9 implementation, for concurrent use. This has streamlined the integration between D7VK and DXVK code, and opened up a way for... downstreaming (of sorts)! Read the next section for more information on that angle.

Upstreaming? No. Downstreaming? Yes!

Thanks to efforts by @pythonlover02, D7VK has been backported to DXVK-Sarek. This is good news for anyone still using an only Vulkan 1.1/1.2 capable GPU, most notably Nvidia Kepler cards, or older generations of Intel iGPUs. Mind you, performance on that kind of hardware won't be exceptional anyway, but it will most likely be enough for D3D7 and earlier D3D APIs.

Apart from some missing features, which sadly aren't supported by Sarek's aging DXVK backend, you are getting all the bells and whistles D7VK has to offer. Impressively, DXVK-Sarek now supports everything from D3D3 up to D3D11.

Before you get too excited, it's probably best to wait for the next DXVK-Sarek release before giving it a go, because some backport enhancements and quality of life improvements are still underway, now that I've started actively looking into it as well. You'll be happy to hear DXVK-Sarek is also getting a backport of the latest legacy lighting model work, a rewrite on top of DXVK's legacy shader compiler.

Here are a couple of screenshots taken with the in-flight backport code:

DXVK-Sarek - Sacrifice	DXVK-Sarek - Codename: Outbreak

It's lovely to see these old games workable on even older Vulkan-capable hardware, and thanks again to @pythonlover02 for his work in maintaining DXVK-Sarek and his openness and support in backporting these ancient APIs.

Have fun with the new release, and remember to report any problems you stumble into, especially if you've giving D7VK a go with any obscure/hard to obtain games that have flown under our radar so far.

Version 1.6

This release features a general overhaul and cleanup of D7VK's interaction with DXVK's D3D9 backend, particularly in the area of vertex processing, but also in terms of VSync handling.

The former is expected to technically improve GPU bound performance. And I say technically because being GPU bound in D3D7 and earlier APIs requires a potato level GPU and is only really noticeable in benchmarking. Still, some games such as Praetorians will get a noticeable boost because of the improved handling of SYSTEMMEM buffers, which are now marked with DYNAMIC usage. 3DMark 2000/99 scores will also see some positive impact.

Apart from that, this release also fixes a few regressions, mostly affecting D3D5 titles, which were brought about by the addition of D3D3 support in v1.5. It also captures a fair share of general bugfixing, enabling more early D3D titles to be playable, such as:

DethKarz

Total Annihilation: Kingdoms

Moto Racer

Fixes/additions:

• Tweaked vertex processing mappings, which generally improves performance and addresses various buffer locality issues, fixing crashes seen in Age of Wonders II: The Wizard's Throne and Escape From Monkey Island.
• Exposed DDCAPS2_FLIPNOVSYNC and flip interval capabilities in DDraw, with proper handling. This has enabled previously greyed out VSync controls in Re-Volt.
• Fixed a regression in Deathtrap Dungeon, caused by D3D3-D3D5 viewport interoperability.
• Thanks to @CkNoSFeRaTU, a bug affecting the D3D6 renderer (background color clears in particular) in Need for Speed III: Hot Pursuit was identified and fixed.
• Fixed invalid color key update skipping during SetTexture() calls, which has fixed various color key transparency artifacts in Moto Racer.
• Fixed a D3D6 specific bug which caused alpha blending states set by the application to be wrongly overridden. This has fixed missing transparency issues in Need for Speed III: Hot Pursuit, Slave Zero and potentially other titles.
• Worked around a color keying precision issue in Metal Fatigue.
• Handled an oversight in texture re-mapping during swapchain resets. This has fixed occasional texture corruption following mode switches in Vampire: The Masquerade - Redemption, Crusaders of Might and Magic, Tony Hawk's Pro Skater 2 and Total Annihilation: Kingdoms.
• Worked around a game bug in Total Annihilation: Kingdoms which prevented video cut scene playback and menu animations from working correctly.
• Advertise the full (non-LAA) 32-bit 2 GB of memory space when reporting texture/video memory. This has been increased from 1 GB previously, since D3D7 and earlier games have been observed to overflow only above 2 GB. This is needed and useful because some later D3D API titles (including some later D3D9 games) query DDraw to consult overall memory availability.
• Thanks again to the superb investigative skills of @CkNoSFeRaTU, we've worked around 8-bit mode/texture support needed by DethKarz, in order to prevent a startup crash and missing in-game textures. The game will now start properly and use 16-bit textures by default.

The Glide king is dead, long live the Glide king!

In a rare case of a D3D(6) renderer offering more features than its Glide counterpart, I strongly encourage anyone playing Total Annihilation: Kingdoms to use D3D, for its native support of 16:9 resolutions, better texture filtering options (only bilinear, actually, but even that is missing in Glide) and hardware cursor support.

D7VK v1.6	Glide (via nGlide)

Now go forth and have some retro D3D fun! And do please report any bugs you come across, should they not already be present on our issue tracker.

Version 1.5

Not so long ago I said I am not going to work on supporting D3D3... and I haven't, really. It was @CkNoSFeRaTU who volunteered and implemented execute buffers, so we pushed the remaining piping onward, to have D3D API completeness after all. Yes, you heard that right, we now support D3D3 as well, which was the last piece of the D3D puzzle in the DDraw world. In addition to all that, v1.5 includes a lot of improvements and fixes for "higher API" games.

"But what happened to D3D1, 2 and 4?", you may ask. See here.

Back buffer and depth write-back

Quite a few games relied on having access to back buffers and depth stencils post presentation, and were getting blank data beforehand because of our reliance on DDraw. Recent advances in "moving bits around" technology have enabled us to somewhat address the problem. See for yourselves how it has helped Drakan: Order of the Flame:

D7VK v1.4	D7VK v1.5

Both pause menu backgrounds and save game screenshots are correctly captured now. Mind you, games that capture such images via GDI or other cursed side-stepping ways that can't be addressed solely in D3D (cough, Black & White, cough) are still very much unfixed.

Fixes/additions:

• Execute buffers have been implemented thanks to @CkNoSFeRaTU, which means both D3D3 games, and D3D5 games that relied on execute buffers (e.g. Incoming, O.D.T.: Escape... Or Die Trying, Star Wars: Shadows of the Empire), are now supported.
• Back buffer and depth write backs have been implemented and enabled where needed, which has fixed games such as SimCity 4, Total Club Manager 2003, Nocturne, The Mystery of the Druids, Gorky 17, Delta Force 2 etc.
• Also thanks to @CkNoSFeRaTU various situations where games were passing incorrect viewport depth values have been identified and fixed (Summoner, Empire of the Ants (2000), Urban Chaos).
• Fixed a texture filter type mismatch with caused issues in Knight Rider and potentially lowered mip map filtering quality in other games.
• Added support for Begin/Vertex/End buffer streams in D3D5/6, which was needed by Frogger (1997). As a result, it is now fully playable.
• Fixed missing geometry in several older ATI tech demos (Radeon's Ark, Rage Dawning).
• Fixed a bug that prevented the selection of 32-bit color modes in Ground Control.
• Fixed missing loading screen artwork in Need For Speed 3/4 (modern patch).
• With some help from @CkNoSFeRaTU, fixed a bug which prevented color key transparency from being applied in Wing Commander: Prophecy.

The black sheep of D3D: a D3D3 showcase (guest starring D3D5)

In some ways you could say execute buffers were ahead of their time, but for a 3D API which wanted to market itself on ease of use, they simply were too convoluted and hard to grasp. As a result, not a lot of games came out on this particular rendering path, however, there are still enough titles for a modest showcase:

Moto Racer 2

Outlaws

Star Wars: Shadows of the Empire

Star Wars: Jedi Knight: Dark Forces II

Take No Prisoners

Venom. Codename: Outbreak

Incoming

O.D.T.: Escape... Or Die Trying

As I've said before, in the time of D3D3 (also 5 and 6) Glide was king, so if any games offer the choice between the two, there's really no contest. In some of these games 3D acceleration didn't even offer much benefit beyond improved texture filtering, but you can now enjoy them with D7VK, at least for the sake of nostalgia or for historical reasons. Enjoy!

Version 1.4

Hasn't been all that long since v1.3, however several key new features (pun intended) being added to D7VK warrant their own rollout. In addition to that, D3D6/D3D5 game compatibility has been expanded, with many other titles now being operable.

Color key transparency

The star of the show this time is color key transparency. "What is it?", you may ask. Well, in short, a cheaper alternative to alpha testing which was somewhat common in early D3D, and that could be applied on various color values (typically black) associated to textures. It had the benefit of working even on hardware that didn't support alpha formats (such graphics cards existed in those prehistoric times, alongside cavemen and dinosaurs).

Pictures are worth 1000 words, so here's a comparison of how N.I.C.E 2 looks between D7VK v1.3 and v1.4:

D7VK v1.3	D7VK v1.4

Fixes/additions:

• Thanks to the efforts of @CkNoSFeRaTU, we now (finally) have support for color key transparency, which gets rid of opaque color artifacting in a lot of games, such as: Arx Fatalis, Messiah, Darkstone, Divine Divinity, Mortal Kombat 4 and many others.
• A lot of work has gone into consolidating legacy DDraw interoperability with all the supported D3D versions, which means Plants vs Zombies and possibly other PopCap Games titles of the time are now playable.
• Also thanks to @CkNoSFeRaTU, a bug related to DDraw instancing via IClassFactory has been fixed, and as a result Re-Volt and Sea Dogs are now playable.
• Thanks to some intriguing hints from @Trass3r, support has been added for DDraw initiated depth clears, which has fixed rendering in Star Wars Episode I: Racer.
• Preliminary support for depth write-back has been added, as of now only supporting D16, which has fixed light source occlusion, or rather the lack thereof, in Star Wars Episode I: Racer.
• Fixed a bug which caused a crash on startup in V-Rally 2 Expert Edition.
• Fixed various corner cases which caused hangs and crashes in older D3D and DDraw titles (the latter of which simply loaded our dll and crashed), e.g. Revenant, Powerslide, Slave Zero etc.
• Worked around a potential crash in GTA 2 on returning to the main menu.

I don't have much to showcase for this one, but maybe only a sneak peak at what working fog looks like in Star Wars Episode I: Racer and how it really contributes to the game's atmosphere on some tracks. Make sure you don't miss this gem, it's one of the best Star Wars games out there.

As always, enjoy and have fun!

Version 1.3

I'm afraid we've run out of 3DMark versions at this point, and the Final Reality benchmark isn't yet workable, however this release officially introduces support for D3D5. Don't worry, you won't run into any GPU-related performance limitations in this cursed land of our 3D forefathers, no matter what you use for translation to more modern APIs. Mind you, in the vast majority of cases you're better off using the Glide renderers that nearly all such late last century games offer as an alternative.

In addition to that, the D3D7/D3D6 sides have also seen a fair share of fixes and improvements (see below).

Fixes/additions:

• Starting with v1.3 we are opting in to FSAA emulation, rather than enabling it globally by default and keeping it disabled until the game decides to use it (or not). That will save quite a bit of memory bandwidth, since it does away with multi-sampled surface use, unless a game is known to offer support for FSAA. You can still force enable FSAA emulation at your leisure, of course, however note that AMD users may run into issues with it in some cases due to a known driver limitation around 16-bit texel buffers.
• Also starting with v1.3 logging verbosity and log file path environment variables are prefixed with D7VK_, to allow for better logging segregation between D7VK and DXVK.
• Thanks to @CkNoSFeRaTU, an obscure FPU mode setup bug, that affected all D3D6/5 titles, was spotted and fixed. The new way of handing things has done away with glaring rendering issues in titles such as Legacy of Kain: Soul Reaver (yes, Raziel is finally play-worthy, as he should be!), Homeworld: Emergence (aka Cataclysm) and subtle precision issues in many others.
• Fixed a D3D6/5 texture loading oversight which prevented us from hitting an optimal level of performance in many D3D6 titles (e.g. Drakan: Order of the Flame, Freespace 2 and Arabian Nights) and sometimes caused texture corruption.
• Thanks again to the now notorious detective skills of @CkNoSFeRaTU, we've managed to do away with our proxy interface workaround, which technically enables various games to run under Windows (e.g. Gothic 1/2, Ground Control, No One Lives Forever, Blood 2: The Chosen and other LithTech engine games) and ensures intro videos and other back buffers surfaces used by these games are displayed properly.
• Finalized an assortment of DDraw legacy surface groundwork, which was needed to properly support various D3D5 games.

A short story about the first somewhat sane D3D API: D3D5

Back in the Windows 95 era, game developers were in a bit of a bind. Microsoft was pushing them to try out their new toy: D3D(3) immediate mode, but that API was, frankly speaking, absolutely awful. A few games adopted it, but the rest simply didn't bother and only implemented software renderers with optional Glide support for hardware acceleration.

But then something emerged, shyly. After a lot of brainstorming and rearchitecting, and a canceled DX4 release, DX5 and D3D5 came out and introduced a new way of handling draws, namely a DrawPrimitive/DrawIndexedPrimitive path, which was... fairly sane compared to its predecessor, and one that lasted, with minor adjustments, well into the glory days of D3D9. Which is why, ultimately, it wasn't an impossible task to add support for D3D5 in D7VK (... not that it was what I'd call a pleasant affair either).

And although some may say that D3D5 brought about the slow but inevitable decline of Glide, which may or may not be true, in truth Glide remained the main focus of developers well into the D3D7 area, with D3D renderers failing to meet it on even grounds in terms of performance and features in most cases. Therefore, consider D3D5 (and to some degree D3D6) support to be purely historical, and if a game offers the option of using Glide, always pick that with prejudice.

That being said, here's a few well supported titles you can try out today, in case you're nostalgic for Win9x era jank:

Carmageddon II: Carpocalypse Now

Tomb Raider II

Mortal Kombat 4

Nightmare Creatures

N.I.C.E 2

Mobil 1 Rally Championship

Deathtrap Dungeon

Lands of Lore III

As a final fun fact, some of these releases coexisted with the last generation of DOS games, released on CD-ROM(s). I, for one, never thought I'd see such titles run on the DXVK backend, yet here we are. As always, feel free to report any issues which aren't already on the issue tracker, and most of all have some early D3D fun!

Version 1.2

This release improves support for the D3D6 frontend, while fixing up and adding features on top of the existing D3D7 implementation, and, since D3D6 is... a bit less experimental now, something had to take its place. Do peak at the spoiler below, that is, in case you haven't been following the recent commit history:

Ancient D3D secret

Don't get too excited though, because this D3D archeological expedition has reached its final stopping point. Even with D3D6/5 we are firmly in the land of diminishing returns, where most games offer better rendering capabilities on Glide, aren't even working at all in Wine due to various cursed reasons which are unrelated to graphics, or are simply doing things so cursed that there's no plausible approach for supporting them in D7VK.

For more details on the D3D6-related work, check out the highlights section below.

Fixes/additions:

• A somewhat fundamental rewrite of our DDraw wrapping logic, which was needed because I did not anticipate adding support for earlier APIs when I started this project, and everything was an absolute mess. The end effect is transparent to end users, albeit it does come with the side effect of better memory management. Granted, memory pressure has never been a problem in the context of these early APIs.
• Added an alternative deployment option for Wine/Linux which allows some stubborn games to load D7VK from the system path, as they would otherwise ignore it. More details can be found in the readme. Note that this will NOT work on Windows.
• Fixed device capability reporting, which allows Conquest: Frontier Wars to properly detect D3D7 support and enables in-game resolution switching.
• Added a vertex processing workaround which helps 1NSANE get full levels of performance regardless of T&L HAL/HAL device choice.
• The Need for Speed III: Hot Pursuit and Need For Speed: High Stakes modern patch now fully works with D7VK, both with its D3D7 and D3D6 renderers, both of which offer better capability support than the D3D8 renderer (lack of fogging being the most obvious gripe in the latter).
• Added an IClassFactory implementation for DDraw since some games (mainly D3D6/5 titles) were relying on it to properly instantiate DirectDraw (for whatever odd design choice) and crashed on startup otherwise.
• Various compatibility fixes to get 3DMark 99 Max in working order out of the box (you need no "modern patch/ fixed exe" with D7VK now), see #66 . Thanks to @archeYR for that bit of investigative work.

And now, a word from our new "sponsor", D3D6:

The biggest motivation for adding D3D6 support, by far, was Drakan: Order of the Flame , as I am a big fan of the series and have both the PC original in retail box and the PS2 exclusive sequel in its jewelcase sitting on a display stand in my living room.

I've already played quite a bit of the game with D7VK (or D6VK, if you will), as you'll see in the below screenshot showcase, and, outside of some minor issues like the lack of savegame screenshots and pause menu backgrounds (both of which are inherent limitations, sadly), it works beautifully.

Before we get into actual games, there's the obligatory, yet somewhat irrelevant, benchmarking to get out of the way. Irrelevant because 3DMark 99 Max is VSync capped by default, and there's no way to disable it with WineD3D (or, at least I'm not aware of one). I have however disabled VSync in D7VK via a builtin config option, so you all can now heat up your rooms by throwing modern GPUs at it, heh. Here are the results on my Nvidia RTX 4070:

D7VK v1.2 (VSync)	WineD3D (VSync)	D7VK v1.2

Drakan isn't, of course, the only noteworthy D3D6 title in existence, so, while testing the release, I've put together a showcase of what works well at this point:

Drakan: Order of the Flame

Battlezone II: Combat Commander

Earth 2150

Expendable

Rayman 2: The Great Escape

Tomb Raider: Chronicles

Indiana Jones and the Infernal Machine

Star Wars: Rogue Squadron

Tachyon: The Fringe

Arabian Nights

Panzer Elite

And now, to the bugfixmobile, because there are plenty of things still in need of fixing.

I know I've complained about the lack of tooling for these early APIs, and that still mostly holds true save for the brave efforts of @CkNoSFeRaTU, who's been working on bringing the apitrace support for early D3D and DDraw in a decent shape, and adding replay and inspection capabilities for them. By all means, investigating what goes wrong in most cases is still challenging, but now at least a technical possibility.

Version 1.1

Polishing up some rough edges of v1.0, v1.1 also adds a new experimental front-end to D7VK. There's a spoiler about it below, since I heard you folks like dragons. More details on the topic can be found in the project's readme file (see the FAQ section).

Spoiler

Fixes/additions:

• Added a workaround for Sacrifice which enables the game to properly use 32-bit color / z-buffer depth. This is a known problem/limitation of the game, which tries to use D32 for depth and falls back to 16-bit if it is unavailable (D32 has always been generally unsupported, and is unsupported universally on modern drivers). The workaround vastly improves distant geometry rendering as can be seen in this comparison:

  Out of the box behavior

  
  Workaround applied

  

• Added support for strided primitive rendering, thanks to @CkNoSFeRaTU, which means Sacred is now playable.

• Worked around missing/swapped mip maps in Star Trek: DS9: The Fallen (#58), thanks to @esdrastarsis.

• Added a workaround for Conquest: Frontier Wars, which enables the use of D7VK for in-game rendering, assuming 3D acceleration and the desired resolution are set up beforehand. The game relies on highly cursed DDraw interoperability to work, so getting anything out of it is nothing short of a miracle.

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

The next few releases will most likely focus on bringing the new front-end up to snuff and out of its experimental phase. Support for some games, such as Drakan: Order of the Flame, Earth 2150 (and expansions), Expendable, Tachyon: The Fringe, Tomb Raider Chronicles and Arabian Nights is already provided with this release, so feel free to give it a go.

Version 1.0

The time has finally come to draw the line and officially slap the label of "production ready" onto D7VK. This doesn't quite mean that all the bugs are fixed, or that all the missing features are implemented, but it does mean that well behaving D3D7 games are now well supported and work without any issues.

Why bother with D7VK at all?

The good (vs WineD3D):

• Anti-aliasing / D3DRENDERSTATE_ANTIALIAS support (you can also optionally force enable it)
• targeted performance fixes for bad behaving games (looking at you, 1NSANE)
• built-in frame caps for games known to break at high frame rates, or simply over 60 FPS (which is, sadly, quite common in D3D7)

The bad:

• A few missing D3D7 features, that I'll most likely add at some point in the future
• General WSI wonkiness on Wayland

The ugly:

• Quite a few remaining bugs
• A cursed design that by some miracle happens to work well enough in most cases

You'll still need to use WineD3D for:

• Earlier D3D and DDraw
• Games that make use of cursed legacy DDraw <-> D3D7 interop (thankfully, it didn't turn out to be entirely all that common)
• Its excellent general compatibility and feature coverage
• GPUs that don't support Vulkan 1.3

Benchmarking

Here is an admittedly apples to oranges comparison done using 3DMark 2000's standard benchmark run and a Nvidia RTX 4070 with the 570.195.03 drivers:

D7VK v1.0	WineD3D*

*Wine Staging 11.0-rc1 was used, with its OpenGL backend. Wine's Vulkan backend would not run 3DMark 2000 at all for some reason.

Acknowledgments

None of it would have been possible without the work of the WineD3D developers (for the underlying DDraw implementation) and the upstream DXVK dev team (especially @doitsujin, @misyltoad, @K0bin and @AlpyneDreams).

Many thanks to @elishacloud and @CkNoSFeRaTU as well, for their helpful hints and, ehm, very clever and cursed workarounds that I'm sure I never would have come up with myself.

And of course @Blisto91, for being eternally supportive of all my antics and half-mad ancient API endeavors. P.S.: Don't believe a word he says - he's actually a dev, but in denial.

D3D7 games spotlight

And last, but not least, here's a selection of screenshots featuring some of my favorite D3D7 titles, now all fully supported by D7VK:

Sacrifice

Dark Reign 2

Emperor: Battle for Dune

Clive Barker's Undying

Unreal Tournament

Vampire: The Masquerade - Redemption

Hitman: Codename 47

Disciples II

Giants: Citizen Kabuto

No One Lives Forever

Deus Ex

Colin McRae Rally 2.0

Star Trek: Bridge Commander

Carmageddon TDR 2000

Black & White

Wizardry 8

It's time to work on that backlog!

Enjoy, and please remember that "newer isn't always better". Some of these now "ancient" D3D7 games are truly awesome and fully deserve our appreciation, even in this day and age.

Version 0.6

Probably the final v0.x release before the long awaited v1.0, it adds support for a few noteworthy D3D7 capabilities.

Fixes/additions:

• Fully operational D3D7 anti-aliasing, controlled through D3DRENDERSTATE_ANTIALIAS (this has been made possible through upstream work by @doitsujin). As a consequence, the swapchain MSAA forcing option has been altered to become an AA force toggle, which enables AA regardless of application preference.
• Support for cube map textures and uploads, providing proper environment cube mapping in Giants: Citizen of Kabuto and Colin McRae Rally 2.0 (though there are still some pending issues with the latter).
• Fixed VSync handling, aligning D7VK to native D3D7 behavior of having it on, unless applications are really adamant about turning it off. Application level VSync control now works properly in games like Unreal Tournament (with the OldUnreal patch).
• Proper handling of DDSCL_MULTITHREADED. Yes, DDraw had a multithreaded safe mode, in the age of single core CPUs... and yes, it very much caused issues when we weren't taking it into account.
• Fixed a sleuth of shadow projection, dynamic lighting and texture cropping issues in games, due to improper handling of D3DTSS_ADDRESS (which sets the wrap mode for both U and V coordinates in one shot)
• Properly support multiple back buffers (double, triple, quadruple buffering... some applications insist on the latter). Not without some exceptions though, because of how certain games blit content directly onto the front/back buffers.
• Report available video/texture memory based on the maxAvailableMemory d3d9 config option, and default to 1024 MB for D3D7. This fixes overflow crashes in Hard Truck 2 and startup errors in 3DMark 2000.

Now go ask Santa Claus for a D7VK v1.0 present this year, but only if you've been nice.