Divinity: Original Sin 2

Divinity: Original Sin 2

View Stats:
Milky™ Sep 15, 2016 @ 2:59pm
Will this come to Linux?
Hey all. Big fan of divinity etc. Bought both classic edition and then later enhanced. Because I knew they were porting it towards Linux? Unsure though if this is coming to Linux? Anyone know as I only have my steam machine now which is steamos.

So don't want to purchase to find out after a long time that they are not doing a Linux version.

Any thoughts? Shoot!
< >
Showing 1,156-1,162 of 1,162 comments
I am also interested in playing Divinity: Original Sin 2 on Linux! :steamhappy:
I still hope to see this game release on Linux, and would buy it the moment it were to become available.
Xaekai Feb 11 @ 11:07pm 
Originally posted by Coffee:
Random question kinda, why is gaming on Linux is so hard?

Looking back at the past 25 years....

Historically the only real solution if you wanted a high-performance game on Windows, was to use DirectX. DirectX is a very Windows-centric proprietary API suite from Microsoft.

In theory, OpenGL kicked DirectX's ♥♥♥ for performance. In practice there was a minefield of caveats. The necessary skills needed to write a best-practices OpenGL rendering pipeline are not as common, and the engineers capable of it cost more. The developer tools for DirectX put the OpenGL ecosystem to shame, especially when it comes to debugging and itemizing scene benchmark factors. Microsoft knew that to really monopolize the gaming market they needed a lot of sugar to entice developers into their vendor lock, so they spared no expense in creating their SDKs. OpenGL had very little sugar to offer, things like RenderDoc didn't exist at the time.

Then a few years later they created the Xbox game console, and of course it's underlying OS offered just one media API: DirectX. Where do you think the X in Xbox came from?

So then, if you wanted to target 90% of the computer market and a third of the home console market, your game engine must target DirectX. This is an embedded cost. Abstracting that layer, the rendering pipeline, to include other choices is an additional cost and those costs have to provide ROI.

The only reason other game consoles get such a pass on this is they are a static target. That is, their API and any quirks are set in stone and the developer doesn't have to worry about some software change or driver update on a Playstation making their game no longer work. This means you can ship a really fragile solution and still get away with it. If these APIs played by the same rules as a PC, where the possibility of a driver update requiring possible maintenance intervention on the developers part, they'd never get supported.

Another factor that played into this was "middleware" -- That is premade libraries designed to solve a specific problem for the developer. For example, the libraries created by RAD Game Tools. These had massive adoption, the two most famous being Miles and Bink.

Miles Sound System:
Started to add support for Linux in 2003, with official release "soon"
Linux support finally released in 2010, seven years later...

Bink Video:
Basic Linux support came out in 2003, but the support was terrible and the implementation was not performant. It has some severe bugs that didn't all get resolved until about 2005. But performance was still pretty bad until about 2007, and that was only a side effect of work they were doing to improve it for PS3. Linux support finally was decent by 2010, not because they were good coders, but by 2010 CPUs were powerful enough they were able to abstract a lot of their code.
Linux kernel supported x86 64-bit builds in 2001, before the physical hardware was even released. By 2003 several Linux distros offered complete 64-bit repos. Bink didn't support 64-bit Linux until 2012.

And this is what you get from the first middleware most studios would turn to.

Looking at the situation now:

I can say with a lot of confidence the only reason Linux doesn't get more direct gaming support is the existing inertia. All of the above factors created a lot of inertia. Much like a domestic violence victimized spouse of a police officer, she just doesn't know how to leave. It's a self-fulfilling prophecy..
Xaekai Feb 12 @ 12:18pm 
Originally posted by rusty_dragon:
Native linux executables(elf files) don't work through Proton.

All Proton is Wine with DVXK and a few other minor patches.

DVXK is the actual magic where the Direct3D-to-Vulkan magic happens, and there is already effort underway to migrate it from being a Wine DLL to a native Linux so. This means Wine would be using it on the native side instead of the emulated side.

It also means that Native Linux executables could indeed directly target a DirectX rendering rendering pipeline.



Originally posted by gibblets:
Stadia

I have heard that Google has a small in-house team that gets access to the source code of games that Stadia-signed studios are having a difficult time porting, and they finish the port. However that compiled binary is not for release. Only Google can use it and those porting efforts do not get shared back with the original game studio. I can't confirm that information, however if it is true, then Stadia does absolute nothing to help Linux users.


Originally posted by rusty_dragon:
What this single guy tries to do is to make own business out of providing developers with half-arsеd automated ports.

No. That's not what this is.

The move of DVXK from a Wine compiled DLL to a native Linux SO that Wine can hook into is how upstream Wine maintainers have wanted things arranged for a while now.

The fact that after once that is done, game studios could theoretically build a native Linux binary against while maintaining there usage of the DirectX rendering pipeline they are already familiar with is just a bonus.

I don't think you understand the cause-effect of the angle you are pushing. Everything game studios do is a calculated cost. Getting a team that's already knee-deep in their understanding of DirectX to just abandon all that to learn Vulkan is a high cost. Hell even now, a lot of studios are still using DirectX 11 because DirectX 12 is radically different. It's low-level, just like Vulkan. Either way, there is a great many studios very familiar with DirectX, years of experience in it and an aversion to change, and anything that lets them use DirectX11 natively on Linux makes porting games cheaper and more likely.

Generally the rest of the issues of porting are absolutely non-issues for a lead engineer, unless they were foolish enough to use un-abstracted Windows native threading.

The only real damning hindrance to porting that's kinda not apparent to your average Linux user is that middleware, though most support Linux these days, charge separately per platform.

You want RAD Game Tools for your Windows title? $25000
You want RAD Game Tools for the Linux port of that same title? Another $25000!
(not to single RAD out, this behavior is a common feature across middleware)
Originally posted by Xaekai:
I have heard that Google has a small in-house team that gets access to the source code of games that Stadia-signed studios are having a difficult time porting, and they finish the port. However that compiled binary is not for release. Only Google can use it and those porting efforts do not get shared back with the original game studio. I can't confirm that information, however if it is true, then Stadia does absolute nothing to help Linux users.
If this is true, it would not be all that bad. Yes, it's worse than having a publicly supported Linux build for sale, BUT it employs Linux professionals, it emphasizes the importance of porting knowledge to the market, and if a games developer has already done their own Linux port, it certainly helps them get Stadia working because they will not need to use the Stadia porting team, maybe not even sharing their source code with them. So, there is still an incentive for Linux compatibility on the developer side, and that's what we are needing the most.
Last edited by Patola [Linux]; Feb 15 @ 3:03pm
Originally posted by Patola Linux:
Originally posted by Xaekai:
I have heard that Google has a small in-house team that gets access to the source code of games that Stadia-signed studios are having a difficult time porting, and they finish the port. However that compiled binary is not for release. Only Google can use it and those porting efforts do not get shared back with the original game studio. I can't confirm that information, however if it is true, then Stadia does absolute nothing to help Linux users.
If this is true, it would not be all that bad. Yes, it's worse than having a publicly supported Linux build for sale, BUT it employs Linux professionals, it emphasizes the importance of porting knowledge to the market, and if a games developer has already done their own Linux port, it certainly helps them get Stadia working because they will not need to use the Stadia porting team, maybe not even sharing their source code with them. So, there is still an incentive for Linux compatibility on the developer side, and that's what we are needing the most.

I agree with this response but let's keep in mind that the previous statement was completely unsubstantiated heresy posted by some random dude on Steam. This means it's not true.
Mandril Feb 16 @ 1:14pm 
Originally posted by Schattenspiegel on Linux:
Why not just wait for the Linux version (that we all hope is comming) and buy once it is released?
Buying the Windows version and then hoping for a port does send the wrong signal to the Devs and will only lead to frustration.
"|
there was some discussion by Steam a while back if you bought a PC game that works flawless on SteamPlay...Linux would get the credit for it meaning it would show as linux purchase and not windows/...am 60+ hours in runs smooth as hell on Linux if you decided to get it follow the work around posted on protondb.com
< >
Showing 1,156-1,162 of 1,162 comments
Per page: 15 30 50