It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
shmerl: I think it's on Wine devs being too stubborn about it. dxvk should be included in Wine same as vkd3d-proton.
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.
avatar
vv221: 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.
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.
Post edited October 08, 2024 by shmerl
avatar
rojimboo: My understanding is that the gamespecific settings and fixes are applied when making the Wine/Proton prefix. They are just Python scripts with usually things like Wine DLL overrides based on game ID.
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.
avatar
shmerl: Not change, but they could at least make an effort to accommodate it. I think it's doable. But they didn't want to.
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.
avatar
vv221: 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.
Post edited October 09, 2024 by shmerl