Metro Exodus is still planned to release for Linux and macOS

Also, 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).

Also, 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.

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 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…

And 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?

I 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). :(

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?

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 Nov 2020 at 3:47 pm UTC

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.

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.

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.

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.

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.

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 Nov 2020 at 6:06 pm UTC

...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...

This. Exactly my stance.

Man, this is like the The Witcher 2 argument all over again. My personal view is that whatever is under the hood is largely irrelevant, provided it performs reasonably. That's a vague term, and dependent on your hardware, sure, but "native" for me is nothing to do with wine, dxvk, togl, indirectx or whatever is doing the translation. It's whether the developer is willing to put a Linux logo on the store front.

As for Wine Is Not an Emulator? It amazes me people still care about this recursive "joke" and the distinction it implies. It runs Windows software in Linux, with a performance hit. Who cares if it's actually a re-implementation of the underlying windows system calls? As Alm888 notes, if it looks like a duck, walks like a duck... we may as well call it a duck. No-one who isn't a pretty hard-core Linux nerd will care about whatever that distinction means in real terms.

I already finished the game using Proton, but a native Vulkan port will be a great excuse to do a second run


Last edited by ziabice on 26 Nov 2020 at 6:29 pm UTC

So what do you all think of the game, any good?

I've been playing through the STALKER series and loving it. This gives me similar vibes, which I like.

Man, this is like the The Witcher 2 argument all over again. My personal view is that whatever is under the hood is largely irrelevant, provided it performs reasonably. That's a vague term, and dependent on your hardware, sure, but "native" for me is nothing to do with wine, dxvk, togl, indirectx or whatever is doing the translation. It's whether the developer is willing to put a Linux logo on the store front.

As for Wine Is Not an Emulator? It amazes me people still care about this recursive "joke" and the distinction it implies. It runs Windows software in Linux, with a performance hit. Who cares if it's actually a re-implementation of the underlying windows system calls? As Alm888 notes, if it looks like a duck, walks like a duck... we may as well call it a duck. No-one who isn't a pretty hard-core Linux nerd will care about whatever that distinction means in real terms.

You also probably think FPGA implementations are emulators? :p

My favorite recursive acronym was MiNT, which initially stood for MiNT is Not TOS. Atari couldn't come up with their own mutitasking thing so snagged that and called it MiNT is Now TOS.

There is NO inherent performance hit with Wine. It is simply a matter of whether or not the APIs are are implemented correctly and they translate well to a performant equivalent in Linux. This is why somethings are faster and other things are slower. This is also why it is strictly NOT emulation. So you are calling a moose a duck just because it can quack.

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.

And I completely agree with the last part you mention. But still, I also think that creating an specific build environment to get the game into our platform (i.e. working with native dependencies and a compiler for our platform) gives an extra value to their work as this means that game developers get away from their Windows building cage they usually live in.

BTW, I don't think that Wine is blasphemous, I just appreciate more one work than the other.

Man, this is like the The Witcher 2 argument all over again. My personal view is that whatever is under the hood is largely irrelevant, provided it performs reasonably. That's a vague term, and dependent on your hardware, sure, but "native" for me is nothing to do with wine, dxvk, togl, indirectx or whatever is doing the translation. It's whether the developer is willing to put a Linux logo on the store front.

As for Wine Is Not an Emulator? It amazes me people still care about this recursive "joke" and the distinction it implies. It runs Windows software in Linux, with a performance hit. Who cares if it's actually a re-implementation of the underlying windows system calls? As Alm888 notes, if it looks like a duck, walks like a duck... we may as well call it a duck. No-one who isn't a pretty hard-core Linux nerd will care about whatever that distinction means in real terms.

You also probably think FPGA implementations are emulators? :p

My favorite recursive acronym was MiNT, which initially stood for MiNT is Not TOS. Atari couldn't come up with their own mutitasking thing so snagged that and called it MiNT is Now TOS.

There is NO inherent performance hit with Wine. It is simply a matter of whether or not the APIs are are implemented correctly and they translate well to a performant equivalent in Linux. This is why somethings are faster and other things are slower. This is also why it is strictly NOT emulation. So you are calling a moose a duck just because it can quack.

Yep. And, like, five people care about that distinction. Or fifteen. Hell, let's make it a couple of hundred. Ar we happy now? It's irrelevant!

Man, this is like the The Witcher 2 argument all over again. My personal view is that whatever is under the hood is largely irrelevant, provided it performs reasonably. That's a vague term, and dependent on your hardware, sure, but "native" for me is nothing to do with wine, dxvk, togl, indirectx or whatever is doing the translation. It's whether the developer is willing to put a Linux logo on the store front.

As for Wine Is Not an Emulator? It amazes me people still care about this recursive "joke" and the distinction it implies. It runs Windows software in Linux, with a performance hit. Who cares if it's actually a re-implementation of the underlying windows system calls? As Alm888 notes, if it looks like a duck, walks like a duck... we may as well call it a duck. No-one who isn't a pretty hard-core Linux nerd will care about whatever that distinction means in real terms.

You also probably think FPGA implementations are emulators? :p

My favorite recursive acronym was MiNT, which initially stood for MiNT is Not TOS. Atari couldn't come up with their own mutitasking thing so snagged that and called it MiNT is Now TOS.

There is NO inherent performance hit with Wine. It is simply a matter of whether or not the APIs are are implemented correctly and they translate well to a performant equivalent in Linux. This is why somethings are faster and other things are slower. This is also why it is strictly NOT emulation. So you are calling a moose a duck just because it can quack.

Yep. And, like, five people care about that distinction. Or fifteen. Hell, let's make it a couple of hundred. Ar we happy now? It's irrelevant!

There is a thing called latency and it is real. People who use things such as the MiSTer can pretty much tell right away the differences to the Raspberry Pi. So just because you don't care, does not mean others do not.


Last edited by slaapliedje on 28 Nov 2020 at 3:46 pm UTC

Man, this is like the The Witcher 2 argument all over again. My personal view is that whatever is under the hood is largely irrelevant, provided it performs reasonably. That's a vague term, and dependent on your hardware, sure, but "native" for me is nothing to do with wine, dxvk, togl, indirectx or whatever is doing the translation. It's whether the developer is willing to put a Linux logo on the store front.

As for Wine Is Not an Emulator? It amazes me people still care about this recursive "joke" and the distinction it implies. It runs Windows software in Linux, with a performance hit. Who cares if it's actually a re-implementation of the underlying windows system calls? As Alm888 notes, if it looks like a duck, walks like a duck... we may as well call it a duck. No-one who isn't a pretty hard-core Linux nerd will care about whatever that distinction means in real terms.

You also probably think FPGA implementations are emulators? :p

My favorite recursive acronym was MiNT, which initially stood for MiNT is Not TOS. Atari couldn't come up with their own mutitasking thing so snagged that and called it MiNT is Now TOS.

There is NO inherent performance hit with Wine. It is simply a matter of whether or not the APIs are are implemented correctly and they translate well to a performant equivalent in Linux. This is why somethings are faster and other things are slower. This is also why it is strictly NOT emulation. So you are calling a moose a duck just because it can quack.

Yep. And, like, five people care about that distinction. Or fifteen. Hell, let's make it a couple of hundred. Ar we happy now? It's irrelevant!

I care and I'm a rooster, so that counts for 10000000000000000 people.

On a serious note, the people behind Wine literally put Wine is not an emulator in the name, to prevent people from calling it an emulator. Because it is simply not an emulator. Yet you have people still calling it an emulator. Calling WINE an emulator is not far from calling DXVK an emulator.

"Wine is not an emulator" is a half joke. Not only Wine emulates Windows, it can even emulate x86 on ARM (hardware emulation for the win!) to run Windows programs on Android for example. So not sure what's the point to waste time on arguing about it.


Last edited by Shmerl on 27 Nov 2020 at 7:32 am UTC