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:
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.
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.
If you need to translate lock-in, I'd surely call it non native, VM or not.
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_wingI 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.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?
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.
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.
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
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).
Native:
application → abstraction → system API → …. → hardware
Non native:
application → abstraction → foreign system API → translation → system API …. → hardware
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.
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.
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
Patreon
PayPal
See more from me