One Wine related project I completely missed writing anything about is DXVK [GitHub], a Vulkan-based compatibility layer for Direct3D 11 for use with Wine.
I've been keeping an eye on it, but I only realised today I've not even put up even a most basic article letting people know it exists. It's seeing rather fast-paced development too, with a new version being released only yesterday.
The latest release has added in: Improved support for deferred contexts, Initial support for some D3D 11.1 features, Clipping and Culling planes, an on-disk pipeline cache and more.
It's intended to work with Wine 3.4, to hopefully give you better performance in certain games run through Wine. It's like the VK9 project [GitHub], which is aimed at Direct3D 9 although DXVK has more people working on it and much faster development.
I'm now subscribed to their feed, so I will keep up to date on each new release as it comes in.
It's interesting to see what will become of this, since the Wine developers are working on their own Vulkan implementation.
Quoting: lejimsterQuoting: LeopardI can run Dying Light native without problems on Nvidia binary. If you are a Mesa user , you must force OGL version to 4.5 via launch options.Quoting: noxQuoting: lejimsterI've thought about trying this with Dying Light as I can't get the native Linux version to launch.Hello fellow vega 56 user!
Just force the gl version:
MESA_GL_VERSION_OVERRIDE=4.4 MESA_GLSL_VERSION_OVERRIDE=440 %command%
:)
Thanks, but I guess I should have been more specific. It appears to be an Arch issue that only effects Mesa users. I think some other distros suffer the same problem. I tried for hours different work arounds, even following GloriousEggroll's snap package guide and it still wouldn't launch :'(.
Interesting. I had no issues on arch when I tried it a month or so ago. What exactly is the issue?
Quoting: noxQuoting: lejimsterQuoting: LeopardI can run Dying Light native without problems on Nvidia binary. If you are a Mesa user , you must force OGL version to 4.5 via launch options.Quoting: noxQuoting: lejimsterI've thought about trying this with Dying Light as I can't get the native Linux version to launch.Hello fellow vega 56 user!
Just force the gl version:
MESA_GL_VERSION_OVERRIDE=4.4 MESA_GLSL_VERSION_OVERRIDE=440 %command%
:)
Thanks, but I guess I should have been more specific. It appears to be an Arch issue that only effects Mesa users. I think some other distros suffer the same problem. I tried for hours different work arounds, even following GloriousEggroll's snap package guide and it still wouldn't launch :'(.
Interesting. I had no issues on arch when I tried it a month or so ago. What exactly is the issue?
I get a black screen with white loading bar at the bottom, it fills up and then crashes out.
Log file always goes something like this..
{14:41:30.422} INFO: [INFO] > Caught signal 11 (Segmentation fault).
{14:41:30.426} INFO: [INFO] > /usr/lib/libc.so.6(+0x348e0) [0x7f6ce555a8e0]
{14:41:30.426} INFO: [INFO] | libengine.so(_ZN12CTextManager10InitializeEv+0x26f) [0x7f6ce6fc78ff]
{14:41:30.426} INFO: [INFO] | libengine.so(_Z13CreateTextMgrv+0x40) [0x7f6ce6fc7a50]
{14:41:30.426} INFO: [INFO] | libengine.so(_ZN9CRenderer13LoadResourcesEv+0x2c) [0x7f6ce6fb50bc]
{14:41:30.426} INFO: [INFO] | libengine.so(_ZN5CGame10InitializeEPciPvS1_jjP18IProgressIndicator+0x2370) [0x7f6ce6a8e5b0]
{14:41:30.426} INFO: [INFO] | /mnt/Data/Steam/SteamLibrary/steamapps/common/Dying Light/DyingLightGame(main+0xa45) [0x43e315]
{14:41:30.426} INFO: [INFO] | /usr/lib/libc.so.6(__libc_start_main+0xea) [0x7f6ce5546f4a]
{14:41:30.426} INFO: [INFO] | /mnt/Data/Steam/SteamLibrary/steamapps/common/Dying Light/DyingLightGame() [0x4425d9]
Quoting: lejimsterThanks, but I guess I should have been more specific. It appears to be an Arch issue that only effects Mesa users. I think some other distros suffer the same problem. I tried for hours different work arounds, even following GloriousEggroll's snap package guide and it still wouldn't launch :'(.FYI there's a long thread in the forums about this problem. You guys might want to move the conversation there to keep this one on topic.
Quoting: razing32This is interesting
Did not know about the D3d9 one.
Methinks more games shall run soon :)
Definitely! The question is: What do we do about it? The more Windows titles work with Wine, the less people want to wait for a native version, the less will ask for one, the less demand for Linux games will be seen on Steam.
Wine gamers will get no support for their platform, but count as Windows users. I think we should always be aware of that.
Quoting: NeverthelessDefinitely! The question is: What do we do about it? The more Windows titles work with Wine, the less people want to wait for a native version, the less will ask for one, the less demand for Linux games will be seen on Steam.
Wine gamers will get no support for their platform, but count as Windows users. I think we should always be aware of that.
This was discussed at length already. Linux games (I assume you mean native Linux games) depend on engines support for Linux, and engines support is improving quite well, regardless of Wine. Case in point - Unreal, Unity, Cry, Nitrous and etc. So amount of native Linux games is growing healthily.
The only ones who are pressured by Wine competitively, are other wrapper developers such as Feral and VirtualProgramming. They'll have to cope with competition and adapt their approach. For example by open sourcing their own wrappers.
Last edited by Shmerl on 26 March 2018 at 2:52 pm UTC
Quoting: ShmerlQuoting: NeverthelessDefinitely! The question is: What do we do about it? The more Windows titles work with Wine, the less people want to wait for a native version, the less will ask for one, the less demand for Linux games will be seen on Steam.
Wine gamers will get no support for their platform, but count as Windows users. I think we should always be aware of that.
This was discussed at length already. Linux games (I assume you mean native Linux games) depend on engines support for Linux, and engines support is improving quite well, regardless of Wine. Case in point - Unreal, Unity, Cry, Nitrous and etc. So amount of native Linux games is growing healthily.
The only ones who are pressured by Wine competitively, are other wrapper developers such as Feral and VirtualProgramming. They'll have to cope with competition and adapt their approach. For example by open sourcing their own wrappers.
There are already developers saying they can't deliver a Linux version, but hey, the game works on Wine, why don't you just use that instead? There will be more of those in the future, PLUS Feral and Aspire have harder times porting native Versions.
Quoting: NeverthelessThere are already developers saying they can't deliver a Linux version, but hey, the game works on Wine, why don't you just use that instead? There will be more of those in the future, PLUS Feral and Aspire have harder times porting native Versions.
There are also developers who always claimed they can't support Linux version because they have no time / resources / etc. Wine doesn't change their attitude, they simply don't want to support it.
Wine as an excuse is quite silly, if their own engine supports Linux natively. It's simply rephrasing their "we have no resources for it". How would they have gotten more resources, if Wine wouldn't have existed?
Last edited by Shmerl on 26 March 2018 at 3:16 pm UTC
Quoting: ShmerlQuoting: NeverthelessThere are already developers saying they can't deliver a Linux version, but hey, the game works on Wine, why don't you just use that instead? There will be more of those in the future, PLUS Feral and Aspire have harder times porting native Versions.
There are also developers who always claimed they can't support Linux version because they have no time / resources / etc. Wine doesn't change their attitude, they simply don't want to support it.
It's just not my point. Linux is the last open gaming platform to be. While it is good to have most games playable on Linux, it is essential to have most of them natively on Linux, because otherwise no one will see a Linux market anymore. Therefore I am not concerned about developers that hate Linux, but about the others to stop native Linux versions, because it's cheaper for them to just point at Wine.
Quoting: NeverthelessIt's just not my point. Linux is the last open gaming platform to be. While it is good to have most games playable on Linux, it is essential to have most of them natively on Linux, because otherwise no one will see a Linux market anymore.
Again, this is addressed with engines, Wine has no impact on that. Wine only impacts wrapped games market. So far I don't see any indication of native engines support for Linux slowing down because of Wine progress.
Last edited by Shmerl on 26 March 2018 at 3:27 pm UTC
Quoting: ShmerlQuoting: NeverthelessThere are already developers saying they can't deliver a Linux version, but hey, the game works on Wine, why don't you just use that instead? There will be more of those in the future, PLUS Feral and Aspire have harder times porting native Versions.
There are also developers who always claimed they can't support Linux version because they have no time / resources / etc. Wine doesn't change their attitude, they simply don't want to support it.
Wine as an excuse is quite silly, if their own engine supports Linux natively. It's simply rephrasing their "we have no resources for it". How would they have gotten more resources, if Wine wouldn't have existed?
It's easy to say you don't have the resources, even if you had them...
And again, every Linux user purchasing a Windows game for Wine, that still has a chance for a native Linux version, is a -1 for Linux statement.
Last edited by Nevertheless on 26 March 2018 at 6:43 pm UTC
See more from me