It’s not about stubbornness. Unless I’m misremembering you are a developer yourself, so you know that you can’t realistically change your whole software build toolchain just to include an alternative renderer, especially with a codebase as impressive as the WINE one.

The DXVK dev knew about that when they chose a language incompatible with the existing WINE codebase, so they knew from day one it could not be integrated upstream. This lack of inclusion is on them, not on WINE devs.

To avoid confusion: I am very happy that DXVK is a thing, it is useful for many games of the D3D10/D3D11 era. I would rather have the current suboptimal situation with DXVK unmergeable into WINE than no DXVK at all.

Not change, but they could at least make an effort to accommodate it. I think it's doable. But they didn't want to. Understandable on one hand (i.e. their idea is that if you want something better - build it yourself and add those dlls which anyone who cares to have good performance on Linux does). But on the other hand, they could make it more seamless.

May be another factor is project governance. dxvk and vkd3d-proton are independent of Wine and can make their own decisions and move fast. May be they didn't want to be governed by whoever makes final decisions in Wine project.

Language choice in my opinion is not a blocker for project inclusion though, and having strict requirement for C only is what I would consider stubbornness. But I don't think it's the real reason here anyway as above. More likely a combination of macOS problem and managing the project.

Not having to be online while the game runs sounds good. But unfortunately there's no database or any other kind of store for the game settings. The necessary tweaks are hardcoded in python scripts, not a good design choice.

As someone who works on software maintenance I can assure you that no, they could not "make an effort to accommodate it". This is not about willingness at all, but simply not technically doable without majorly disrupting WINE development and maintenance.

This is going to be my last post about this, as it seems we are running in circles here.

I would have dropped whole autotools from Wine and replaced it with a better build system first if that was my project. And then accommodated the above.

It is a big effort though and I surely don't mean that it's trivial. But it's not impossible.

Would it be possible to get an updated Underrail wrapper?

As far as I know, GOG does not provide a WINE wrapper for UnderRail.

it seems to work with Proton 8.0-1 and Proton 7.0-1.

Please excuse the stupid question, but could somebody please elaborate on what "override for msadp32.acm" actually means? I.e. what I need to do? (I'm trying to run this game in Mint 22.3 using Wine)

Kao the Kangaroo 2 runs perfectly under Linux Mint 22 with WINE 9.0
The other two Games seem to do the same way: Games start and first level is playable (not tested any fruther as I'm playing the 2nd part at the moment).

Talisman Digital Edition works flawlessly,too. Even additional Content is no problem...

I got annoyed at always disabling mime associations and symlinks for common locations when creating new Wine prefixes, so I just made a script that takes care of that when making a new prefix, if anyone needs.

Interesting commands in that script. Thanks! :)

As probably everyone who is using wine also has installed winetricks you alternatively could use the "winetricks sandbox" command to create the prefix and avoid the symlinks. I'm not sure though if that creates exactly the same behavior as your script.

I did not run into problems with the mime settings so far. When do the default mime settings create problems? Could you give an example when it's better to disable the mime associations?

It didn't create any specific problems for me, but I just see it as clutter. It might be useful for some edge cases that rely on it with Wine, but I never needed that for my games, and never had an issue not enabling these mime settings.

Thanks for the explanation!