Version 1.12

While further CPU ProcessVertices optimizations have been postponed, and the swapchain rework has been benched indefinitely, the latter because it has proven to be more trouble than it's worth, this release still (somehow) manages to roll out quite a few noticeable performance improvements.

But let's start with the overall performance improvements of various APIs since their official introduction in D7VK. Mind you 99% of what you will be seeing are CPU improvements, since being GPU limited in these early APIs is a tough ask even on the most sluggish of modern GPUs*.

*Note: While I have upgraded my GPU drivers since v1.2/v1.0 times, my hardware configuration has remained the same, so the numbers are as like to like as they'll ever get.

D3D6 - 3DMark 99 Max:

D7VK v1.2	D7VK v1.12

D3D7 - 3DMark 2000 v1.1:

D7VK v1.0	D7VK v1.12

Some micro-optimizations have been added specifically in this release and can, at times, have a dramatic effect in CPU limited scenarios.

Unreal Tournament - D7VK v1.11	Unreal Tournament - D7VK v1.12

Fixes/additions:

• Rebased on top of the recently released DXVK 3.0.1, which brings numerous fixed function fixes and improvements into early D3D as well.
• Pulled in an upstream regression fix for bump map texture stages. As such, bump maps are now again applied correctly instead of being MIA.
• Simplified the color key transparency implementation, which removes the need for a fallback tolerance mode.
• Optimized wrapped surface checks by tuning for fast lookup times vs insert times, which improves CPU-bound performance overall and rather drastically in D3D7 multi-texture stage situations, such as in Unreal Tournament with the OldUnreal patches.
• Handle texture use of non-texture surfaces, which fixes white 3D models in The Sims: Complete Collection.
• Improved handling of partial viewport clears, which fixes most, but not all, rendering problems in Star Trek: Starfleet Academy.
• Aligned default VGA adapter naming with native DDraw, which was needed by the Matrox TechDemo 3D sample.
• Optimized D3D6/5/3 viewport clear color transforms, which speeds up the calls ever so slightly.
• Removed advertising of stipple transparency (aka screen-door transparency) in D3D6/5, since apparently it wasn't supported even on age-accurate GPUs, such as the Riva TNT2.
• Tweak the assignment of texture/material handles, which now happens explicitly when an application requests them, not on texture/material creation. This helps reduce the overall handle count.
• Added a loader validation logic to prevent D7VK from loading its own dll and causing endless recursion. This could happen if D7VK's dll was copied to the system path without properly renaming Wine's ddraw.dll first (to ddraw_.dll). In case a self-load is detected, D7VK will now error out instead of live-locking.
• Properly handle devices created with Wine's custom device GUID, which is an alias for HAL as far as D7VK is concerned. This isn't common in most applications, but can be useful for apitrace playback.

Happy retro gaming and enjoy the extra speed, or battery life, depending on your platform (reminder that all early D3D APIs enable VSync, unless the application goes out of its way to disable it... and very few games bother to do that).

Version 1.11

This release is somewhat uneventful feature wise, but rolls out several additional performance improvements to our not so long ago added CPU ProcessVertices implementation, and also includes the usual amount of bugfixes and game specific workarounds, as per the below changelog. These will affect a few prolific titles, but I'll save the feature highlight for some of the more obscure ones. This one in particular goes to the 🐸s.

Fogger (1997)	Frogger 2: Swampy's Revenge

Parallel point lights

We've had this rare type of lights on our radar for quite some time, although D7VK outright rejected their creation before v1.11. They were only ever supported by D3D6 and earlier D3D APIs and their use was limited to only two known titles: The Sims and Hidden & Dangerous. As such, handling them wasn't exactly a priority. In this release we've added a fairly accurate emulation path which is compatible with both our CPU-driven vertex lighting and DXVK's fixed function lighting (done with shaders).

The difference in both games is hardly noticeable, as these types of lights really play second fiddle to the more common directional lights, and are never used by themselves. On early graphics hardware they were only ever useful as a computationally cheaper alternative to point lights, but such concerns are unfounded on any "reasonably modern" GPUs of the early 21st century.

The only exclusive use of parallel point lights we are aware of can be found in the DX6.1 SDK D3D light sample. Here's a video of how it looks now with D7VK, in case you are haunted by an academic curiosity.

Fixes/additions:

• Added support for D3DLIGHT_PARALLELPOINT lights, by emulating them with maximum range and no attenuation point lights. This has had a minor visual impact on The Sims and Hidden & Dangerous. Other, yet unaccounted for, early D3D titles may be positively impacted.
• Pulled in the latest upstream DXVK code, including a fix which drastically improves the compilation speed of the fixed function shaders. There's a global positive impact, and one of a greater degree in particular on HW T&L D3D7 games.
• Properly handled a rare case of cross-API texture interface use, which has fixed rendering in Grandia II (thanks to @CkNoSFeRaTU for spotting the problem).
• Added a workaround for front buffer emulation which has fixed missing load screens/backgrounds in Praetorians and Empire of the Ants.
• Fixed a bug that caused missing texture transparency on Nvidia cards in Frogger (1997).
• Worked around color key precision issues in Frogger 2: Swampy's Revenge.
• Fixed various v1.10 regressions and missing validations caused by our now reduced use of proxied DDraw objects.
• Added a workaround to improve draw performance in Star Trek: Armada.
• Fixed black screen during intro video playback in Age of Wonders II.
• Improved device creation speed, positively affecting games which spam multiple devices on initialization to test for hardware support (e.g. Empire Earth).
• Improved the robustness of our D3D3 implementation.
• Added several tweaks to reduce the CPU usage of (CPU) ProcessVertices calls. While generally unimportant, these will improve CPU bottlenecks in games and mods which abuse SWVP calculations in conjuction with draws.
• Fixed an oversight which prevented proper texturing in GoldSrc titles such as (the original) Half-Life (thanks to @CkNoSFeRaTU). That being said, please don't use D3D6 with any GoldSrc games, as it performs quite poorly when compared to OpenGL.
• Added several workarounds for (the original) The Sims games & DLCs, with the caveat that there are still a few known problems with some versions of the game. These have been, by far, the most horrendous things I've had "the pleasure" to fix/work around so far.
• Fixed several global handle sharing cases, which are specific to early D3D APIs and DDraw. A GTA 2 bug should now resolve itself once the underlying problem is also addressed in Wine's DDraw implementation.

For the next release we've taken on the rather daunting challenge of both squeezing the most performance possible out of our CPU ProcessVertices implementation by throwing some SSE2 at it (this one's on @CkNoSFeRaTU), and to finally, and hopefully permanently, properly synchronize DDraw's swapchain flipping with DXVK's D3D9 backend swapchain flipping. See you all on the next one, with hopefully some good news on both fronts.

Version 1.10

Even the major 2D improvements in v1.9 weren't nearly enough for some games, so in v1.10 we've managed to squeeze a bit more performance in 2D heavy titles by skipping data copies on surfaces which would have been overwritten anyway.

Sounds logical and easy enough, but believe me when I say that dealing with the myriad of corner cases DDraw has to offer and figuring out when it is safe to skip an operation is hardly an easy task. I was even a bit too optimistic at first and @CkNoSFeRaTU had to pull me back to reality, but thankfully most of my optimizations have survived the test of time.

It's not anything nearly as groundbreaking as the jump between v1.8 and v1.9, but it's still something, especially in the worst possible situations, such as the inventory screen in Omikron: The Nomad Soul:

Omikron: The Nomad Soul v1.9	Omikron: The Nomad Soul v1.10

Swapchain fixes and front buffer emulation

In addition to performance improvements, v1.10 also addresses various flickering issues we've had due to an oversight in our back buffer mapping logic. The new approach should also provide a bit less input latency than before, not that it is generally of much concern with these early titles anyway.

While improving things in that department, it also became apparent we were not meeting an expectation of DDraw swapchains, namely that a permanent front buffer should always retain the on screen data, and serve as a source or destination for blits. It became apparent some games were missing backgrounds during pause menus which relied on this effect, but since DXVK's D3D9 backend does not cater for this situation we had to get a bit creative and emulate our way around it.

As all good things in life, this doesn't come for free though, and implies an additional image copy, but we do need to resort to it on occasion, to ensure things are displayed as expected. An obvious example is the in-game pause screen of Warhammer: Dark Omen:

Warhammer: Dark Omen v1.9	Warhammer: Dark Omen v1.10

Fixes/additions:

• Improved the performance of 2D heavy scenarios by skipping D3D9 image downloads of surfaces which would be overwritten during DDraw blits. This provides minor improvements is most 2D heavy games, and more impactful ones on occasion, such as in Omikron: The Nomad Soul and SCP – Containment Breach.
• Implemented front buffer emulation, fixing missing backgrounds and camera effects in: Escape from Monkey Island, Evolva, Black & White, Tomb Raider: The Last Revelation, Tomb Raider Chronicles, Star Wars: Episode I - The Phantom Menace, Descent: FreeSpace, FreeSpace 2, Warhammer: Dark Omen and Interstate '76.
• Thanks to @CkNoSFeRaTU, added a workaround to prevent startup crashes in Interstate '76 and Interstate '76: Nitro Pack, making both games fully playable in D3D(5) mode.
• Also thanks to @CkNoSFeRaTU, added a workaround to fix missing geometry in COPS 2170: The Power of Law.
• Added a workaround to fix a black screen in the Eschalon: Book I launcher (which uses D3D7).
• Also thanks to some investigative work by @CkNoSFeRaTU, added a workaround to restore projected shadows in Expendable.
• Fixed a regression introduced in v1.9 which could cause rendering issues with mixed D3D3-D3D5 device use.
• Thanks to @CkNoSFeRaTU, identified and implemented a workaround to fix window creation behavior in Star Trek: The Next Generation - Klingon Honor Guard, which is now fully playable. Other early / D3D6 Unreal Engine titles may be positively impacted.
• Fixed a rare texture upload quirk which caused minor rendering artifacts in Z.A.R.
• Fixed various issues which prevented Powerslide both from starting at all and rendering correctly (also thanks to @CkNoSFeRaTU for fixing a minor execute buffer oversight).
• Cleaned up logging and reduced our dependency on proxied D3D objects coming from the underlying DDraw implementation, which somewhat improves overall CPU bound performance and reduces memory overhead.

A short rant on the scalability of ancient D3D games on modern systems/GPUs

Not long ago, I ran across a forum comment expressing surprise at how poorly some of the showcased games performed and asking something in the lines of (and I'm paraphrasing): "Shouldn't these ancient games run at 50.000 FPS on modern GPUs?". The short answer to that is: "it's complicated."

You see, there are two categories of ancient D3D games:

• a) Games developed by people who understood that in order to implement efficient 3D rendering you have to respect some basic etiquette, not stall the GPU or move data around needlessly
• b) Everything else

Perhaps I'm a bit too harsh here, since it's true most games at the time were targeting and happy with 20-30 FPS on the hardware of their age, so doing things that would absolutely penalize performance on modern hardware like locking the back buffers repeatedly to blit (yes, blit, not render) one line of text at a time was not that great of a concern.

Games in category b) will most definitely not run "at 50.000 FPS" on any GPU, no matter how modern, simply because they were designed in a different time and played by very different rules. The good news, however, is that there are also quite a lot of category a) games out there which scale just fine on modern hardware and you can play them @8K without issues if you want, at least in theory. DDraw could never display anything above 2048x2048, as a reminder, and we honor that limit, though some patches/mods may work around it.

The bottom line is: don't expect every ancient game to scale properly, not with any wrapper or even on modern Windows, because it's not really the norm, rather the happy exception of what is a very cursed set of D3D APIs with a whole lot of DDraw (2D) baggage dragging them down. In most cases, playing these type of games at their original intended resolutions will provide the best experience (and it also comes with a bonus "retro" feel of pixel gazing).

I hope some of the newly supported titles in this release bring back good memories of the olden days, at least to some people. Until next time, I leave you with a bit of trivia from my favorite vehicular combat game: did you know Interstate '76 includes radio poetry recitals?

Version 1.9

It's no big secret that 2D heavy D3D games haven't really been the strong suit of D7VK, to put it mildly... until now. This release marks a major milestone in our support for 2D/3D interoperability. Taking a lesson from the legacy presentation path we've added in v1.8, we've since implemented a system of delayed image uploads and dirty tracking, which postpones any image copies until the last possible moment (in the JIT ethos). This has had a dramatic impact on performance in games which make heavy use of 2D elements and image composition.

Anno 1503 - v1.8	Anno 1503 - v1.9

In some cases, the improvements are not only in performance, but also in overall scene correctness, fixing both missing 3D and 2D elements.

Hogs of War - v1.8	Hogs of War - v1.9

The new tracking system doesn't only guarantee both correctness and better performance, it also:

• lowers GPU usage
• has a lower overall memory footprint (in conjunction with some additional cleanup done for this release)
• generally improves frametime consistency in 2D heavy scenarios

Though well behaving/purely 3D games are mostly unaffected, when considering bad behaving games the differences between v1.8 and v1.9 can be quite dramatic on all accounts.

Combat Mission 3: Afrika Korps - v1.8	Combat Mission 3: Afrika Korps - v1.9

Fixes/additions:

• Implemented full surface dirty tracking, both for DDraw and D3D9 surfaces, with a dramatic impact on performance and the correctness of image composition. This has fixed numerous bugs relating to missing 2D and 3D content, closing over 30 pending issues on our tracker.
• Unified D3D9 objects between object interfaces in order to reduce the overall memory footprint and fix corner case multi-versioned interface use, which has fixed rendering in Dungeon Keeper 2.
• Slightly improved indexed draw performance by tweaking D3D9 index buffer sizes.
• Thanks to @CkNoSFeRaTU we've drastically improved color key transparency precision, especially on Nvidia GPUs.
• Also thanks to @CkNoSFeRaTU, we've fixed clipping related missing geometry and shadows in various games, such as RIM: Battle Planets and Revenant.
• Fixed a color key value overrun issue which was causing white text backgrounds in various Combat Mission series games (discovered by @CkNoSFeRaTU).
• Fixed missing loading screen backgrounds in Gothic 1 / 2.
• Added a workaround for concurrent device use in scene drawing, fixing rendering in The Settlers IV.
• Fixed missing pause screen menu in Metal Gear Solid Integral.
• Fixed a black screen issue with the PlayOnline Viewer (Final Fantasy 11 launcher).
• Added a compatible device name config option, needed to enable hardware acceleration in Dungeon Keeper 2.

Needless to say, all the improvements mentioned above have been made part of both our default rendering path and legacy presentation, to the benefit of both 3D and 2D heavy titles. As such, though we still have a few challenges left to address, I believe we've now cleared our top problem area and have vastly improved compatibility with nearly all early D3D games.

You can expect the usual flow of fixes and improvements to continue in the next releases, however we've run out of miracles in the performance department. With most inefficiencies now addressed, there's only room for some marginal improvements here and there at best. But, should you run benchmarks on the current status quo, I'm sure you won't be disappointed.

Version 1.8

This release rolls out a lot of game fixes, but more importantly introduces two new major features.

First and foremost, we've added proper support for ProcessVertices calls, (bravely) implemented on the CPU by @CkNoSFeRaTU. This has fixed rendering in a sleuth of games across all supported APIs (see the changelog below for more details).

The second major change is that we have ditched proxied presentation entirely and replaced it with legacy presentation. For those of you yet unaware what proxied presentation entailed, in short, it represented our way of dealing with a particular nasty, though sadly not uncommon, form of DDraw interoperability. Early D3D games sometimes relied on blitting images (e.g. GUI elements, text, various overlays, buttons, decorations) on top of an already rendered image, acting as a sort of compositor within the confines of DDraw surfaces.

Proxied presentation dealt with the problem by making sure D7VK image content was synced back to DDraw for this cursed "compositing", however the presentation of the resulting final image was left to WineD3D (or Windows native DDraw), which usually meant using an OpenGL swapchain, with no possibility of a DXVK HUD in sight.

Here is an example of both proxied presentation (left), and the newly introduced legacy presentation (right):

Warhammer: Dark Omen v1.7.1	Warhammer: Dark Omen v1.8

Legacy presentation now additionally takes the final processed/"compositied" image from DDraw and uploads it back to D7VK one last time for presentation with Vulkan. As you can imagine, this involves yet another full image blit, so it is slower, however not much slower in practice. Don't expect to play any of these games in 4K though. The added benefit is, of course, access to the DXVK HUD, the possibility to use all Vulkan tooling you can imagine, and direct control over presentation, which includes applying frame rate limits, controling VSync status, presentation timings etc. Overall performance on this new presentation path is expected to improve slightly in the coming releases.

Keep in mind that legacy presentation is only needed by games which resort to this legacy DDraw "feature set", and should only ever be used for compatibility reasons. Forward looking games, making use of the D3D APIs as intended (at least when any hope for scalable performance was the aim), which means solely GPU driven textured draws, do not need any sort of special "hand holding".

Fixes/additions:

• Implemented proper handling of ProcessVertices on the CPU (thanks to @CkNoSFeRaTU). This has fixed rendering issues in Forsaken, Resident Evil, Praetorians, Hidden & Dangerous, Escape from Monkey Island, Tomb Raider: The Last Revelation and other titles.
• A new legacy presentation path was introduced to replace proxied presentation, which has enabled fixes for missing video content, loading screens and/or missing menu elements in Blade of Darkness, Sacred, Lands of Lore III, Codename: Outbreak, FIFA 2001, FIFA '99, Simon the Sorcerer 3D etc. All games which were previously presented with WineD3D now get full DXVK HUD support, as well as framerate limits and other adjustments where needed (see the config.cpp file for affected titles, since the list is prohibitively long).
• Following some investigation by none other than @CkNoSFeRaTU, an issue causing missing terrain in Age of Wonders II / Age of Wonders: Shadow Magic has been tracked down and resolved.
• Also following an "anonymous tip" from @CkNoSFeRaTU, we've fixed an oversight in D3D light handling which caused broken lights in X: Beyond the Frontier and X: Tension. Both titles are now working correctly.
• Fixed an issue which caused missing intro playback in Divine Divinity.
• Fixed missing pause menu backgrounds in Tomb Raider III.
• Fixed an oversight which caused a startup crash in Hype: The Time Quest.
• Thanks to @CkNoSFeRaTU, we've worked around a scaling issue in Resident Evil which caused background image line artifacts.
• Resolved a regression involving depth stencil copies, by rebasing against latest upstream DXVK (see doitsujin#5596)
• Added builtin config profiles with fixes for many games, including, but not limited to POD, Prince of Persia 3D, Jurassic Park: Trespasser.

ProcessVertices, the bane of D3D

Upstream DXVK has always had a largely bare bones ProcessVertices implementation, which was insufficient for the extended use it was seeing in D3D7 and earlier D3D APIs. As a result, many games were simply missing geometry or rendering barely anything. These issues are now fully fixed thanks to @CkNoSFeRaTU. Here are a couple of highlights from the extended list mentioned above:

Tomb Raider: The Last Revelation	Praetorians

Integer scaling? Is that a PS1 thing I'm too PC to comprehend?

Some early PS1 ports had a very approximate way of handling their scaling calculations, but drivers and hardware at the time were more lenient of slight errors, so the problems went unnoticed. Here's an example of Resident Evil background artifacting, now worked around in D7VK, but exhibiting line artifacts in other implementations and generally on all modern GPUs, even on Windows:

Resident Evil - WineD3D	Resident Evil - D7VK v1.8

Needles to say, I'm fairly happy with the numerous fixes we've rounded up this time, and will actually go back to replaying Praetorians now, since it's one of my favorite real time tactics games of all times. I hope there's something exciting in this one for everyone, but if not, well, there's always the next release.

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!