Wine 3.3 Brings First Vulkan Bits, D3D CSMT By Default

[Xaero_Vincent]

I did not know this was possible (making a regular laptop into a Chromebook). I knew you could put ChromiumOS on it but I don't think that includes Android app support

It doesn't. This is the official ChromeOS with Android support. It required a bit of fiddling to get it running on a Windows laptop. At first there was no wifi nor sound and dmesg was spamming errors but I got those taken care of. However, I'm playing with things to see if I can get the container working on Chromium OS Special Build, which runs on-top the 4.14 kernel.

[oiaohm]

And still, the only game that I care about, GTA V, is going from good to worse
https://appdb.winehq.org/objectManag...sion&iId=32038

There is no open associated bug for the issue reported in wine 3.2 with that game.

https://bugs.winehq.org/show_bug.cgi?id=42609

I would think it would be above bug. Please note its the users of the program who job it is to add things things.

Notice there there is no report on bug 42609 that the issue is existing past wine version 2.3. Because no one has updated bug and no one has associated applications. So developers don't know there is a problem. Yes this is a common problem when people say program got worse and worse and worse with wine where you find bugs not being updated and associated so wine developers know they are a active problem.

There are a few .net fixes in 3.3 don't know if they will help. Some to deal with 32 bit .net exe in 64 bit prefix.

Please note the rate GTA V had was never good. Anything less than gold in wine world is not a good rating.

[ssorgatem]

so... con this run Vulkan apps?
Or is there still something missing?

[andre30correia]

And still, the only game that I care about, GTA V, is going from good to worse
https://appdb.winehq.org/objectManag...sion&iId=32038

use playonlinux and choose the better option for you

[slacka]

And still, the only game that I care about, GTA V, is going from good to worse
https://appdb.winehq.org/objectManag...sion&iId=32038

Did you file a bug report and bisect the regression? In my experience with Wine, the developers are responsive to users that take the time to identify the bad commits. Their bug tracker is just overloaded with low quality reports and too few volunteers to triage.

If you care about GTA V take the time to make good bug reports, and your work will likely be rewarded. Open source software only works when users do their part.

[czz0]

When they're talking about this new controller support in Wine 3x, does that mean you will be able to connect any controller like you would normally in Linux, and it will show up in Windows software like a Xbox 360 controller, without having to use dlls like x360ce?

[oiaohm]

When they're talking about this new controller support in Wine 3x, does that mean you will be able to connect any controller like you would normally in Linux, and it will show up in Windows software like a Xbox 360 controller, without having to use dlls like x360ce?

Wine objective is not emulation yet you just talked about emulation. The new controller support is to provide more ways to detect controllers and provide the interfaces plugging that controller would under Windows to application running under wine. So attempting to get a real xbox controller to show up correctly.

Now emulation other controllers as xbox controllers that would be a specialist feature request.

[oiaohm]

use playonlinux and choose the better option for you

This above advice is path to doom. If you still don't do bug reports the issues can get worse. Lot worse like in time no longer having a version of wine that you can use at all.

You cannot stay on the same version of wine for ever. There is a issue with the way wine is done that video cards have to be entered into a table to provide correct information. This means when you replace you video card with newer older versions of wine cease to function correctly.

So items like playonlinux is nothing more than a temporary stop gap measure yet people treat it that they don't have to do bug reports and wonder why they end up badly burnt.

Even items like staging should be looked at as a temporary stop gap measure as only patches that get mainline can have a regression test performed if a future patch breaks them.

[Hi-Angel]

You cannot stay on the same version of wine for ever. There is a issue with the way wine is done that video cards have to be entered into a table to provide correct information.

Why is it btw? It was always surprising me to see such commits in wine releases. I'm not a fan of doing manually things that looks like they can be automated.

[oiaohm]

Why is it btw? It was always surprising me to see such commits in wine releases. I'm not a fan of doing manually things that looks like they can be automated.

The video card it table its the first to kill you dead. But with the number of dependencies wine has non backward compadible API/ABI updates in libraries also hit old versions of wine a lot. Doing regressions tests with wine on items where people are not regularly reporting causes a lot of backport work make locating problem a lot harder.

The video card table is one of those nasty things where you cannot extract from opengl or even if you had raw hardware access the information applications demand.

1) You have like opengl have 1 text description for a video card and direct x having a different one. Of course you find windows applications that do strings operations on the video card description to decide on what optimisation it should use.

2) due to copyprotection/anti cheat stuff. You have to report the right dll and version numbers for the video card in use of course there is no way to automatically guess that. This is information that has to be manually collected from windows installs or if lucky out of windows driver install packages..

3) There has to be a list of opengl quirks maintained. What are these quirks it where we know the opengl drivers says I can do X feature. But you attempt to use X feature and complete opengl stack collapses on top of you because that feature does not in fact work this first set of quirks.

4) There is a direct x list of quirks that has to be maintained where if you tell application that it has X card and display extra features you can end up with programs going down impossible code paths again this is not something that can be purely automatically collected.

5) Now wine has allowed by registry for you to set a particular card but if that is having quirk applied that you don't need that hurting performance but that also does not prevent applications probing for anti-cheat/copyprotection/registration and getting upset because graphics card and reported information does not match yes you see games saying please update drivers.... At this point you are in totally stuffed with old version.

Of course if you are able to avoid all the above problems this does not avoid the other issues like when freetype updated and the result was all versions without the patch to support that no longer worked. With the number of dependencies wine has something will get you sooner or latter if you attempt to stay on a old version for too long.

Doing a regression test where really old version reported working and new don't at times means backport a lot of different wine patches and hoping that they are not the cause. Its way better if reports are early and tested at the time.