[GOG]: use native builds of ScummVM and DOSBox when available

[imLinguin]

Tested with Alone in the Dark 1 (dosbox) and Beneath the Steel Sky (scummvm)

gogdl will pick available versions with following conditions

• alternative executable isn't set (Game Settings -> Advanced)
• executable is either dosbox.exe or scummvm.exe

possible executables gogdl will look for

	Flatpak	PATH
DOSBox	io.github.dosbox-staging	dosbox
ScummVM	org.scummvm.ScummVM	scummvm

when gogdl is in flatpak container it will attempt to call flatpak-spawn available through org.freedesktop.Flatpak session bus.

If none of the above are available default wine runner will be called

updated to gogdl 1.1.0 that includes this change

Use the following Checklist if you have changed something on the Backend or Frontend:

• Tested the feature and it's working on a current and clean install.
• Tested the main App features and they are still working on a current and clean install. (Login, Install, Play, Uninstall, Move games, etc.)
• Created / Updated Tests (If necessary)
• Created / Updated documentation (If necessary)

[JKingweb]

Would it make sense to also look for DOSBox-X? I'm not a DOSBox-X partisan myself, but it definitely has its adherents, and I can't think of any reason it couldn't also be used.

This would necessitate searching for com.dosbox_x.DOSBox-X and dosbox-x.

[imLinguin]

I seem to be unable to run Alone in the Dark with DOSBox-X flatpak. It complains about missing CD-ROM driver, similarily to com.dosbox.DOSBox. So for compatibility with GOG's windows builds, staging seems to be the only option.

We may also need to add additional PATH lookup of dosbox-staging sometime in the future, various distro packages seem to be inconsistent about it. As far as I know Fedora has dosbox binary for staging while Arch package has it as dosbox-staging. I'll leave that for now, we can reconsider this later on

[JKingweb]

Ah, right, DOSBox Staging is more forgiving when it comes to path matching. Makes sense.

[Nocifer]

As far as I know Fedora has dosbox binary for staging while Arch package has it as dosbox-staging. I'll leave that for now, we can reconsider this later on

Arch's dosbox-staging package has the binary as simply dosbox as well, so there shouldn't be any problem on that front.

[CommandMC]

I've tested this with a couple games and it does appear to be working fine.

Could you link to the commit hash of gogdl we're now using? I assume it's 7c9a6f4?

[imLinguin]

I just found out this breaks compatibility with Diablo
due to it relying on drive letters in paths. I'm open to suggestions on how should we approach this.
One thing that comes to my mind is hardcoding the drive letters for everything except games with ScummVM

[hfc2x]

I just found out this breaks compatibility with Diablo

It probably breaks compatibility with Carmageddon and Tomb Raider (GOG versions) as well, due to the configuration files that come with those games also hardcode the DOS paths, along with whatever is included in the CUE file replacement they use. In the case of both games, it's named GAME.DAT, and the "BIN" file they reference is in lowercase, which causes DOSBox not find it for some reason.

What I did on my end to be able to play these games through Lutris was copy the config they come with by default, back up the old config, and use the modified configs to launch them, which includes changes such as replacing backslashes with forward slashes. I also modified the "CUE" files to all-uppercase so DOSBox can find the "BIN" file properly.

It's a bit of a pain, especially because I use dosbox-staging, which also changes a lot of the settings (for example, imgmount -t cdrom for normal DOSBox becomes imgmount -t iso in staging).

That's the only solution I've come up with lol. There's probably a more streamlined way of doing it, like having a database specifically for DOSBox configuration file changes so no fiddling is required from the user's part.

[CommandMC]

Perhaps make this an experimental feature, disabled by default? Or maybe just an option in the game settings?

Aside, now that #3849 is merged, this PR no longer needs to modify the gogdl binary

[imLinguin]

I'll rebase the branch to remove the gogdl binary. I feel like there is no need for this to be experimental, there are no known implications from using this. I have modified the way we do the setup so that only scummvm games will use Linux paths (without drive letters), working around the issue I mentioned earlier.

[CommandMC]

I see, it wasn't clear to me that the commit was related to that issue (I assumed "relying on drive letters in paths" meant that it relied on them while actually launching the game, so a commit changing how the setup worked didn't seem relevant)
In that case yes, definitely keep it how it is right now