Confused on Steam Play and Proton? Be sure to check out our guide.
We do often include affiliate links to earn us some pennies. See more here.

Cyberpunk 2077 confirmed for Stadia on November 19

By - | Views: 44,893

While the upcoming Cyberpunk 2077 will not support the Linux desktop, it is at least confirmed to be launching on Stadia same-day as other platforms on November 19.

This gives Linux gamers another way to play, with Stadia getting more huge upcoming games, as on Linux all you need is a Chromium browser and a mouse or gamepad hooked up. If your country is in the supported list for Stadia, that is. Google has still yet to announce wider support for the game streaming service.

Stadia getting probably one of, if not the biggest release this year day and date with other platforms with Cyberpunk 2077 is pretty huge news and perhaps a show of how serious Google are about bringing more people and more games over to it.

From the press release:

“Huge in scale and scope, Cyberpunk 2077 is our most ambitious game to date. It’s humbling to see just how many people are looking forward to playing it, and we want to make it possible for as many gamers as possible come November 19th, when the game launches. The Stadia version will allow players to jump into Night City just seconds after the game unlocks for play worldwide without any downloads needed,” said Michał Nowakowski, SVP of Business Development, CD PROJEKT.

"CD PROJEKT RED are known for developing some of the biggest and best games ever created, and Cyberpunk 2077 is sure to deliver as the most anticipated game of the last few years. We're thrilled to announce that Cyberpunk 2077 will be available on Stadia November 19th. Cyberpunk 2077 on Stadia will allow gamers to play on their favorite screens and never have to wait for a download or install to get into, and explore, the depths of Night City," said Shanna Preve, Managing Director, Stadia Partnerships.

Plenty more footage was shown off recently too on the official YouTube, like this one showing off plenty of the vehicles you will be able to get your hands on:

YouTube Thumbnail
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Accept Cookies & Show   Direct Link

They also confirmed that people who buy the game on Stadia will get a set of Cyberpunk 2077-themed digital goodies including: the game’s original score, art booklet, the original Cyberpunk 2020 sourcebook and Cyberpunk 2077: Your Voice comic book, as well as a set of wallpapers for desktop and mobile.

See Cyberpunk 2077 on Stadia.

It's worth noting also, that CD PROJEKT RED have been embroiled in plenty of controversy around Cyberpunk 2077. Video game journalist Jason Schreier has been covering it in detail, with a developer who was apparently confirmed to be working on it posting about the working conditions on Reddit too. Crunch is seriously terrible and it's such a massive shame these big games keep forcing such terrible conditions on developers. 


Don't miss that we're expecting more big Stadia news next week, which we will be following along.

Article taken from GamingOnLinux.com.
11 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.
110 comments
Page: «11/11
  Go to:

Shmerl Oct 30, 2020
Non tative means taking totally foreign (especially lock-in oriented) API like DirectX and re-plugging it to work with native one.

If you need to translate lock-in, I'd surely call it non native, VM or not.
x_wing Oct 30, 2020
Quoting: ShmerlYou could use dxvk without Wine, yes. But it's still wrapping, not a fully native renderer. That's why Feral ones aren't really native either.

By native renderer I mean one that doesn't need translating DX abstractions into Vulkan ones (on whatever stage, at compile time, at runtime etc.).

So, from your definition if I develop something and use SDL as my graphic API I don't have a native game in any platform as I'm using a wrapper for all of them?
slaapliedje Oct 30, 2020
Quoting: x_wing
Quoting: ShmerlYou could use dxvk without Wine, yes. But it's still wrapping, not a fully native renderer. That's why Feral ones aren't really native either.

By native renderer I mean one that doesn't need translating DX abstractions into Vulkan ones (on whatever stage, at compile time, at runtime etc.).

So, from your definition if I develop something and use SDL as my graphic API I don't have a native game in any platform as I'm using a wrapper for all of them?
I wouldn't think SDL is a wrapper. Isn't SDL basically DirectX for non-Windows platforms? (at least that's how I always viewed it. Just an API with a stack for input, graphical output, etc). Just like DirectX.

Ha, the argument of native vs not is kind of like the argument between FPGA and Emulation. There is a difference to a point, but when you think of it all as 'x86 compatible code' then yeah it's all native in that respect.
x_wing Oct 30, 2020
Quoting: slaapliedjeI wouldn't think SDL is a wrapper. Isn't SDL basically DirectX for non-Windows platforms? (at least that's how I always viewed it. Just an API with a stack for input, graphical output, etc). Just like DirectX.

By definition it is a wrapper. And the difference with DirectX is that SDL is actually using DirectX underneath (if required).

Quoting: slaapliedjeHa, the argument of native vs not is kind of like the argument between FPGA and Emulation. There is a difference to a point, but when you think of it all as 'x86 compatible code' then yeah it's all native in that respect.

I don't see an analogy in your example to be honest. The discussion here is that an ELF binary compiled and linked to run on Linux is, somehow, at the same level as PE binary compiled and linked to run on Windows.
Shmerl Oct 30, 2020
SDL is an abstraction that sits above windowing subsystem.

Higher level abstractions don't make things non native, but if you need translate one lower level abstraction to another one because the first isn't supproted, that makes things non native.

I.e. DirectX is native on Windows. It's not native on Linux, so you need to plug all DirectX logic into Vulkan one if you aren't rewriting your code to use Vulkan one directly but used DirectX directly.

Let's say you wrote your code using gfx-rs that can target both Vulkan and DirectX. Then you don't need to replug anything. You are already using an abstraction that can work with both. I hope that explains the difference which I meant.

Basically, abstractions can be helpful. Translating things is a shortcut when you don't want to rewrite them (even if in higher abstractions). Translations add performance cost. Abstractions don't need to, in theory.


Last edited by Shmerl on 30 October 2020 at 8:33 pm UTC
x_wing Oct 30, 2020
Quoting: ShmerlSDL is an abstraction that sits above windowing subsystem.

Higher level abstractions don't make things non native, but if you need translate one lower level abstraction to another one because the first isn't supproted, that makes things non native.

I.e. DirectX is native on Windows. It's not native on Linux, so you need to plug all DirectX logic into Vulkan one if you aren't rewriting your code to use Vulkan one directly but used DirectX directly.

Let's say you wrote your code using gfx-rs that can target both Vulkan and DirectX. Then you don't need to replug anything. You are already using an abstraction that can work with both. I hope that explains the difference which I meant.

Basically, abstractions can be helpful. Translating things is a shortcut when you don't want to rewrite them (even if in higher abstractions). Translations add performance cost. Abstractions don't need to, in theory.

SDL is an abstraction but a wrapper in the end, so you always ends up doing a translation to a lower level api at some point.

Maybe what you should do is to differentiate your idea of "native" (which refers to an engine internal architecture) from the concept of native application (i.e. an application with one OS as target).
Shmerl Oct 30, 2020
I think I explained it above, but let's clarify further:

Native:

application → abstraction → system API → …. → hardware


Non native:

application → abstraction → foreign system API → translation → system API …. → hardware
x_wing Oct 30, 2020
Quoting: ShmerlI think I explained it above, but let's clarify further:

Native:

application → abstraction → system API → …. → hardware


Non native:

application → abstraction → foreign system API → translation → system API …. → hardware

I suggest you to read my second paragraph... but at this point I think that you don't care about what others understands for native applications.
dubigrasu Oct 31, 2020
Regarding how DXVK can be used for certain games on Stadia:
https://www.gamingonlinux.com/2019/11/d9vk-developer-is-working-on-allowing-dxvk-to-help-linux-ports-for-direct3d-to-vulkan

Could be this or maybe a similar implementation, we can't say, but that's the basic idea.
Shmerl Oct 31, 2020
Quoting: x_wingI suggest you to read my second paragraph... but at this point I think that you don't care about what others understands for native applications.

Well, I explained my idea of non native quite clearly before. That's what I was referring to.


Last edited by Shmerl on 31 October 2020 at 11:39 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.