WinterSnowfall/d7vk v2.4

Version 2.4

on GitHub

You know what's scarier than the upcoming All Hallows' Eve? No, it's not this video, it's the things going on in the haunted lands of DDraw and early D3D. But now that D7VK is in maintenance mode no new features were added to v2.4, so surely it's not too spooky, right?

Weeeeellll... there have maybe been two worthy additions overall, and one that Wayland users might be interested in, but it comes with a caveat. Otherwise, the usual number of assorted fixes have made their way into this new release, this time mainly aimed at curtailing a few lingering "shocking" modernisms that send some old games into a panic.

A lot of work has also gone into making the more awful DDraw surface wrapping parts of the codebase a bit more palatable, though the outcome is largely transparent to end users. There's perhaps a slight performance increase in there, but modern CPUs won't care about it too much in practice. Based on the below, there have been at least some slight increments in synthetic benchmarks, with new and improved top 3DMark scores to showcase.

3DMark '99 Max - D7VK v2.4	3DMark 2000 - D7VK v2.4

Early D3D surface size/resolution limits

Traditionally, early D3D and DDraw have had limitations around the maximum supported surface and display mode dimensions, the former being 2048 pixels wide/long and the latter being 2048 x 1536. Quite a number of games will either fall back to a safe default resolution (like 640 x 480) or simply crash when exceeding these limits, so we are now enforcing them and masking higher resolutions even if they are reported by the adapter/monitor.

As a consequence, 1080p becomes the new top "modern" resolution you can use with D7VK. Mind you, there aren't all that many games that will list any non-5:4/4:3 aspect ratio resolutions in the first place, in which case you'd be limited to either 1280 x 1024 or 1600 x 1200 anyway.

Should you insist on having the old behavior back, though there is absolutely no guarantee it will work well in the vast majority of cases, you can enable up to 16K surface sizes and resolutions, by following the guidance in this readme section.

Back buffer stretching and Wayland

In D7VK v2.3 and earlier, we defaulted to stretching the back buffer to fit the screen whenever we detected that the back buffer size was smaller than the screen size. This path was commonly hit on Wayland. For v2.4 this behavior was both enhanced and disabled by default because of known limitations.

Sacrifice - 640 x 480 (X11)	Sacrifice - 640 x 480 fitted to 1080p (Wayland)

What works well:

• In v2.4 we've added a new mode that respects the original aspect ratio when fitting to screen. This is now enabled by default but can be disabled with the ddraw.preserveAspectRatio = False config option.
• The above option won't do anything by itself, and it only works if you manually enable back buffer fitting to the screen resolution, by using ddraw.backBufferResize = True.

Caveats:

• Back buffer resizing is now disabled by default in v2.4 because games that rely on copying between DDraw and D7VK back buffers will NOT work correctly. This is due to the difference in size between these two surfaces. Granted, only a subset of games will be affected, however we chose to err on the side of caution.
• No sharpening or filtering is applied during resizing to minimize performance costs, thus the result can end up looking somewhat blurry.
• The recommended way to handle aspect/display issues with Wayland is now described in the project's readme file, see here. Please only use these D7VK resize/stretching workarounds as a last resort. Doing the work of a compositor isn't exactly a thing that belongs in D7VK in the first place.

GXVK - a Glide implementation on top of DXVK

I know some of you have been asking about this for ages, and it is indeed as exciting if not more exciting than the existence of D7VK. None other than our very own CkNoSFeRaTU has been hard at work, gradually hammering out a (Windows) Glide implementation that makes use of DXVK's Vulkan backend. Check out its early alpha release here, which can already run some games, and keep an eye on it as it develops.

Glide and early D3D have continuously traded blows in terms of features throughout their development, but generally speaking Glide is almost always the better choice vs D3D5/3, whereas in the D3D7/6 age the features "competition" is more nuanced, depending on what game developers at the time chose to invest most of their resources on.

There are also a handful of Glide exclusive games which now get access to an open source Vulkan implementation, which is a great option to have.

Pandemonium 2 - GXVK v0.1	Incubation: Time Is Running Out - GXVK v0.1

Fixes/additions:

• Rebased on the latest upstream DXVK development code, which pulls in present timing, among other things.
• Implemented aspect ratio preservation for back buffer stretching and also disabled back buffer stretching by default.
• Enforced traditional DDraw surface and mode size dimensions where applicable, providing a config option to skip any validations for the more adventurous souls.
• Added a legacy aspect ratio compatibility option which will only report 4:3 and 5:4 modes to an application. This was needed by Earth 2150 and its addons, which crash while accessing certain UI sections when any 16:9 resolution is used.
• Improved present interval handling (and VSync state propagation to the Vulkan backend), which has fixed missing text/artwork issues in Re-Volt and 3DMark 2000, as well as potentially other issues in games/applications that toggle VSync state during presentation.
• Fixed an oversight which caused us to not enable VSync (if it was disabled) when using legacy surface flips.
• Added an option to force proxied gamma ramp handling (using the DDraw swapchain exclusively), which may help resolve gamma ramp issues caused by alternating DDraw/Vulkan swapchain use.
• Moved all bridge handling to the common interface/device objects, as well as improved device/interface creation robustness on failures and in OOM situations.
• Skipped setting any LOD/priority levels on non-MANAGED textures, as per native behavior.
• Slightly sped up cube texture uploads and initial object creation.
• Reworked (D3D9) backend pool selection to be more compliant with newly introduced upstream restrictions.
• Fixed a viewport detachment bug causing null pointer dereferencing, which has fixed crashing in H.E.D.Z. Thanks to @ksc-1 for reporting it.
• Fixed a similar (but purely theoretical) clipper detachment bug.
• Skipped applying a gamma ramp when in actual windowed mode (as dictated by our DDraw overlords).
• Unified all surface description structs into a single backing DDSURFACEDESC2, which reduces memory overhead and slightly speeds up all surface description-related operations.
• Relaxed validations on surface description refreshing, for a slight performance boost.
• Improved vertex buffer lock tracking, to account for multiple possible simultaneous locks.
• Propagated a common shadow surface object across all surface versions, to reduce memory overhead.
• Slightly improved the IClassFactory-based object initialization path, both in terms of speed and corectness.
• Reworked our early HWND caching workaround to always use the latest set HWND until we get an actual value from SetCooperativeLevel calls (some games need that in order to be able to properly create a Vulkan swapchain).

As always, enjoy playing these early D3D titles and get spooked by the horrors that lie below maybe just this once 👻. Oh, and don't forget to welcome GXVK, our Glide sibling project, into the fold!