We do often include affiliate links to earn us some pennies. See more here.

Metro Exodus is still planned to release for Linux and macOS

By - | Views: 47,460

4A Games have confirmed in an official 10th anniversary update post today that Metro Exodus is still going to release for Linux and macOS as well.

They gave a small overview in the post about what's been going on like celebrating the first release of Metro 2033 which arrived back in March 2010. Not only that, they recently got acquired by Embracer Group who also control Koch Media, Saber Interactive, THQ Nordic and others. Specifically, 4A Games are now an independently run subsidiary of Saber Interactive.

For people waiting on official Linux support for Metro Exodus, there's good news. While it has been confirmed for a while now, they have been somewhat quiet on it. When mentioning about bringing it to the latest consoles with the Xbox Series X and the PlayStation 5 they also said this:

Aside from these enhanced versions for Gen 9, we recently brought Metro Exodus to more players through Amazon’s ‘Luna’ streaming service; and we’re also working on dedicated Linux* and Mac versions of the game. We’ll share more information about these closer to release.

*Emphasis ours.

Also confirmed is a new Metro game that is officially under development. They're not sharing anything on that, other than it being built for all modern tech as it's targeting PCs and the latest consoles. 4A also confirmed their commitment to "delivering a great story driven single player experience". On top of that, with Saber's help they're exploring a proper multiplayer Metro title but it's not clear if it will be part of the next Metro game or a title by itself.

Article taken from GamingOnLinux.com.
Tags: FPS, Steam, Upcoming | Apps: Metro Exodus
42 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
109 comments
Page: «7/11»
  Go to:

Alm888 Nov 26, 2020
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).
rustybroomhandle Nov 26, 2020
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.
scaine Nov 26, 2020
View PC info
  • Contributing Editor
  • Mega Supporter
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.
Alm888 Nov 26, 2020
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). :(
x_wing Nov 26, 2020
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.
omer666 Nov 26, 2020
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
x_wing Nov 26, 2020
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.
Alm888 Nov 26, 2020
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
Avehicle7887 Nov 26, 2020
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.
jens Nov 26, 2020
  • Supporter
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
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.