DavidoTek
commented
1 year ago Great! I didn't even know that project exists, it seems like a good addition.
the builds are very regular, but this is still a "nightly" build. For this reason, I kept this gated behind Advanced Mode
Sounds reasonable
An interesting quirk here is that D8VK's Actions build both a "regular" D8VK and build what looks like a "D8VK Native" Regular DXVK nightly ... the native build and regular build are downloaded in the same archive ...
Intersting... That a bit different from DXVK 2.0 https://github.com/DavidoTek/ProtonUp-Qt/pull/140.
Maybe this is far too niche to be added? ... My hesitation here is that, is it worth the "maintenance" cost, so to speak?
I don't think that will be a problem. It will only be shown when advanced mode is enabled, so the available tools list doesn't get too long for regular users, and advanced user may expect that some things break. If there is any reason we cannot maintain it/it gets upstreamed to DXVK, we can remove in the next release.
Thanks!
There is no corresponding issue for this PR, but it's something I thought would be a neat addition! :-)
Overview
D8VK is a project that that implements Direct3D 8 over Vulkan. It is a fork of DXVK. Quite a nifty project! If you remember the days of D9VK before that was upstreamed, it's the same idea.
This PR adds support for downloading D8VK as a DXVK version for Lutris.
Implementation
The D8VK ctmod is very similar to the DXVK nightly Ctmod and actually the DXVK nightly ctmod was used as a base.
D8VK does not distribute full "releases" at least not at the time of writing. Instead you have to download it from GitHub Actions. Luckily, the builds are very regular, but this is still a "nightly" build. For this reason, I kept this gated behind Advanced Mode. Another justification for this is that the versions returned are just commit hashes (just like DXVK nightly), and we would really only want an advanced user to use this feature :-)
An interesting quirk here is that D8VK's Actions build both a "regular" D8VK and build what looks like a "D8VK Native" -- It has the same kind of folder structure as DXVK Native. Regular DXVK nightly does not have this issue and downloads correctly, as the native build and regular build are downloaded in the same archive, with the DXVK Native folder structure being nested inside of the regular folder structure.
However, D8VK packages these as two separate actions builds. Luckily, D8VK's artifacts are conveniently named: the one with
dxvkin the name is the "native" release (which we don't want), and the one with "d8vk" in the name is the correct version. So in__get_artifact_from_commit, we check if the artifact name hasd8vkand we assume that is the correct one. I tested a few versions and it seemed correct, but if you'd prefer a more robust test please let me know :-)There is only a
x32folder because Direct3D 8 is 32bit.Considerations
I have a couple of reservations here that I'd like some input on.
Maybe this is far too niche to be added? I personally don't know if I have very many games that would utilise this, certainly even fewer that I would use with Lutris. But just because I wouldn't use it all the time doesn't mean it won't be useful to some! My hesitation here is that, is it worth the "maintenance" cost, so to speak?
My other concern is the same concern that was raised with implementing this in SteamTinkerLaunch for Steam games: This may eventually be upstreamed. The maintainer of D8VK does contribute to DXVK and they maintain a fairly up-to-date fork from what I can ascertain. I don't know of any immediate plans, and the project has been around for a while I believe, but D9VK initially had no plans at all to be upstreamed. Now it's compatibility that we take for granted in DXVK!
These are just some things worth considering :-) Thanks!