Metro Exodus is still planned to release for Linux and macOS

Quoting: rustybroomhandleAlso, we're not talking about DXVK under wine/Proton, but dxvk library used with a native Linux binary. It's not emulated, it's a proper port.

1) Strictly speaking, WINE is not an emulator as it does not implement software imitations of different hardware, thus, no WINE wrapped game should be called "emulated"; this "proper port" is no more "proper" than any random WINE-wrapped release;
2) DXVK implements DirectX® API (more precisely, Direct3D® 11™) so, ported or not, this (soon™ to be) release is built around a Microsoft® proprietary API with all its quirks and gotcha's in mind;
3) this technique is hardly anything new (see "Winelib" method of getting a native ELF executable via WINE-compilation).

I wonder, how many Linux gamers will re-purchase the game after the (upcoming) release. It's been two years already and I've heard a game gets written off of the accounts (by AAAAA-publishers) after the initial one-month-release-period (at least this time frame is often suggested as crucial for DRM protection).

Quoting: Alm888

Quoting: rustybroomhandleAlso, we're not talking about DXVK under wine/Proton, but dxvk library used with a native Linux binary. It's not emulated, it's a proper port.

1) Strictly speaking, WINE is not an emulator as it does not implement software imitations of different hardware, thus, no WINE wrapped game should be called "emulated"; this "proper port" is no more "proper" than any random WINE-wrapped release;
2) DXVK implements DirectX® API (more precisely, Direct3D® 11™) so, ported or not, this (soon™ to be) release is built around a Microsoft® proprietary API with all its quirks and gotcha's in mind;
3) this technique is hardly anything new (see "Winelib" method of getting a native ELF executable via WINE-compilation).

I wonder, how many Linux gamers will re-purchase the game after the (upcoming) release. It's been two years already and I've heard a game gets written off of the accounts (by AAAAA-publishers) after the initial one-month-release-period (at least this time frame is often suggested as crucial for DRM protection).

I know "Wine Is Not an Emulator" because it does not emulate hardware, but since it still abstracts the API of one OS to run on another OS, "emulator" is a perfectly fine shorthand for that.

And I meant "proper" as in it is native code, as opposed to Windows binaries running under WINE.

I know how a wine-wrapped build works. The Metro port, incidentally, is NOT that either. It just uses dxvk for graphics API translation.

I notice I had you blocked. Wonder why.

Two years or longer - if a game is good, and suddenly gets Linux support, I'm likely to buy it. But it does annoy me that a publisher might then extrapolate lower Linux sales to "there's no market here". I mean, they're not idiots, I guess. They must know that there's no point in doing that. Surely??

But there's been so few truly AAA titles released with same-day Linux support, it must be hard to gauge the impact of Linux sales in any other way.

Quoting: rustybroomhandleI know "Wine Is Not an Emulator" because it does not emulate hardware, but since it still abstracts the API of one OS to run on another OS, "emulator" is a perfectly fine shorthand for that.

And by that extension, using DXVK to abstract a Direct3D API to Vulkan API shall be considered "emulation". Pure logic, how the saying goes: if it looks like a duck, walks like a duck…

Quoting: rustybroomhandleAnd I meant "proper" as in it is native code, as opposed to Windows binaries running under WINE.

Sorry, can you elaborate a bit? What constitutes a "native code" for you? And why it is any different from "Windows binaries"?

You know, being an "*.exe" does not make a "Windows binary": some Mono bytecode files are "*.exe", which does not make these files "Windows binaries". Besides, "*.exe" (or more correctly, "Portable Executable", descendant of "COFF" ) is just a executable code packaging format, nothing more. And while I'm no programmer, it is not evident for me that ELF format is superior (inferior) to COFF/PE. And you do know that after the executable code was unpacked by a loader (be it "ld" or WINE loader) into RAM and was appended to a CPU queue, it ultimately makes no difference for application behavior from there on, right?

Ultimately, it is underlying API dependencies and technologies used in the code that makes something a "Windows binary", is it not?

And what, if the same code using Windows® API was duct-taped with the Direct3D to Vulkan translation layer and repackaged into (arbitrary more true and holy) ELF format, that makes this code suddenly stop being Windows-oriented?

Quoting: rustybroomhandleI know how a wine-wrapped build works. The Metro port, incidentally, is NOT that either. It just uses dxvk for graphics API translation.

Oh, is it so?

And as for your blockade, sorry but I will not return you the favor, as I do not block anybody (I prefer to hear opinions, even if I am not happy with them). :(

Quoting: Alm888Ultimately, it is underlying API dependencies and technologies used in the code that makes something a "Windows binary", is it not?

And what, if the same code using Windows® API was duct-taped with the Direct3D to Vulkan translation layer and repackaged into (arbitrary more true and holy) ELF format, that makes this code suddenly stop being Windows-oriented?

The fact that it uses your native system loader makes the difference. Not to mention that on link time they had to use native linux libraries.

We already had this discussion many times. Your concept of "native" is more related to the software architecture, while our concept is more related on how a binary is loaded and run by the OS. So, like it or not, you may want to differentiate your concept from the other as both are corrects if applied in the right context.

If using a DirectX to Vulkan translation layer means the port isn't native, I'm afraid we don't have many native Linux ports, as far as AAA games are concerned.

The main problem I see with using DXVK is that people know what it is, what it's used for and thus they complain about it. If they had used another layer altogether, nobody would have known what it was and everyone would be having a nice day and all.

Just so you know:
https://www.reddit.com/r/linux_gaming/comments/5cis3p/feral_interactives_indirectx/
https://github.com/ValveSoftware/ToGL


Last edited by omer666 on 26 November 2020 at 3:47 pm UTC

Quoting: omer666If using a DirectX to Vulkan translation layer means the port isn't native, I'm afraid we don't have many native Linux ports, as far as AAA games are concerned.

The main problem I see with using DXVK is that people know what it is, what it's used for and thus they complain about it. If they had used another layer altogether, nobody would have known what it was and everyone would be having a nice day and all.

I think people are very exigent on what means "a real port" and sometimes forgot that the delivery of a software product on a platform it isn't just about code but also about QA and support. More than 50% of the time invested in a port is probably dedicated to testing... and that's also something we pay when buying a product.

Quoting: x_wingYour concept of "native" is more related to the software architecture, while our concept is more related on how a binary is loaded and run by the OS.

OK, I can understand that for someone executable file format can be psychologically important.

But what really irks me is that one can bash a Winelib-port (totally a full-fledged ELF executable) and go as far as accusing WINE to be an emulation, while at the same time praising a DXVK-wrapped port.

Apparently, WINE has a bad reputation here and even mentioning WINE is considered an insult (despite official support from the devs), while DXVK is perceived to be a god-sent for Linux games. So, even comparing usage of DXVK to WINE-wrapping is considered blasphemous by some.

If (when) the game is released with official Linux support, IMO it should not matter what technique was used as long as the quality is reasonably high.

Otherwise I would just suicide knowing every Linux game using Unity3D has over 100 DLL files:

 
$ file ./AlwasLegacy_Data/Managed/mscorlib.dll
./AlwasLegacy_Data/Managed/mscorlib.dll: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows

Personally I'm fine with Metro being wrapped in dxvk. Performance should still be faster than Wine as it's bypassing that overhead.

Unfortunately Vulkan Ray Tracing was finished only recently, even worse only Nvidia supports it at the time. So it's understandable devs cannot wait for that feature, goes without saying that the studio has to move on to newer projects in order to survive.

Now that Vulkan has RT, here's hoping the studio will switch to it instead of persisting with DX12, that would be a mistake.

Quoting: Alm888

Quoting: x_wingYour concept of "native" is more related to the software architecture, while our concept is more related on how a binary is loaded and run by the OS.

OK, I can understand that for someone executable file format can be psychologically important.

But what really irks me is that one can bash a Winelib-port (totally a full-fledged ELF executable) and go as far as accusing WINE to be an emulation, while at the same time praising a DXVK-wrapped port.

Apparently, WINE has a bad reputation here and even mentioning WINE is considered an insult (despite official support from the devs), while DXVK is perceived to be a god-sent for Linux games. So, even comparing usage of DXVK to WINE-wrapping is considered blasphemous by some.

If (when) the game is released with official Linux support, IMO it should not matter what technique was used as long as the quality is reasonably high.

Otherwise I would just suicide knowing every Linux game using Unity3D has over 100 DLL files:

 
$ file ./AlwasLegacy_Data/Managed/mscorlib.dll
./AlwasLegacy_Data/Managed/mscorlib.dll: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows

I’m not sure if this is already known, but I’m posting this link anyway https://github.com/Joshua-Ashton/dxvk-native/issues/1
See the use case of dxvk-native in the link which is not the same as dxvk.

Ps: just to be sure, I’m also much more interested that a game runs nicely and is supported, the technical implementation is really just a detail imho.


Last edited by jens on 26 November 2020 at 6:06 pm UTC