games using dxvk or vkd3d in Lutris aren't listed about protonup-qt HOT 2 OPEN

Indeed, not sure if there's a good way to do this or not.

I wouldn't say this is a bug, though, this is more of a feature request.

from protonup-qt.

DXVK version (and whether DXVK is enabled or not) is stored in the game's YML file (~/.config/lutris/games, or equivalent Flatpak path). It looks like this (vkd3d uses vkd3d keys):

wine:
  dxvk: false
  dxvk_version: v2.1

This will not be listed in the file unless DXVK information is configured explicitly for the game. When adding a game yourself, normally this is not set. For install scripts some may set this. So basically if you don't configure it yourself, the file won't have this information.

There is a gotcha though: The user can enable, say, DXVK, and this will be dxvk: true in the game's YML, but by default it uses the, well, default DXVK version, and this is not listed in this YML file! Fortunately, Lutris does track its defaults in ~/.cache/lutris/versions.json. Sample file structure:

{
  "runtimes": {
    "vkd3d": {
      "name": "vkd3d",
      "created_at": "2023-11-28T00:42:02.989003Z",
      "architecture": "all",
      "url": "https://github.com/lutris/vkd3d/releases/download/v2.11/vkd3d-2.11.tar.xz",
      "version": "v2.11",
      "versioned": true
    },
    "dxvk": {
      "name": "dxvk",
      "created_at": "2023-09-11T20:58:41.103087Z",
      "architecture": "all",
      "url": "https://github.com/lutris/dxvk/releases/download/v2.3/dxvk-2.3.tar.gz",
      "version": "v2.3",
      "versioned": true
    },
  }
}

So, if the game config yaml has dxvk: true (or vkd3d: true), but no dxvk_version or vkd3d_version, we can use the defaults defined in this file. We could store this on the LutrisGame objects.

In the CtInfo dialog, we can't use self.ctool.version because this isn't set for DXVK or vkd3d(-proton). And while we could use self.ctool.displayname, this is risky because of the naming. We append dxvk to the display name if it isn't already present. Lutris saves extracted DXVK versions as, for example, v2.1. For our games list we want to display this more obviously as DXVK, so we the runtime name, f.e. dxvk v2.1. But only if the runtime name isn't already there, so if the folder is named dxvk-2.3, we don't append, so that we don't end up with dxvk dxvk-2.3. See here:

Perhaps storing the version for DXVK and vkd3d(-proton) is the better overall solution here, to avoid parsing out everything after the first space in the string conditionally if we have a certain ctool.ct_type. Not sure how feasible this is, though.

Maybe we need a data class to store general information like this on the LutrisGame, in case we want to get other information in future too, similar to what was described in #346 (comment). Although in that case, we were mapping JSON directly, whereas here we would be working with one yaml file and a JSON file if the runtime is enabled but no version is set...

I messed around with this versions.json file before when working on implementing marking Lutris Wine versions as "global" like we have for Steam, as a follow-up to #314. You can see some of it on a branch I have on my development fork of ProtonUp-Qt: sonic2kk@0171061#diff-2b509fae2fc1ae227755a3c4a401486f5bcbc17608dd2441e61c2dce586b6fdfR55-R90

The approach taken above would probably not apply if we want to generally parse and store the information in this file at the time we build objects.

Not really sure on how we'd want to architect this, but I guess now we know where we can get this information from. The question becomes how we want to retrieve it/store it/etc. We know where to get it, but I don't know the best approach to implement it.

This does not cover Heroic, but we'd probably have to tackle that separately anyway.

from protonup-qt.