Divinity: Original Sin [Official Site] is one game that the stable open source Mesa drivers currently cannot run without hacks, but it looks like the Mesa team has been testing it.
Just today a commit was sent in to Mesa which mentioned "drirc: Allow extension midshader for Divinity: Original Sin (EE)". It's interesting to see game-specific changes like this, as some games will sadly need them.
You can see the commit here, which has already landed in Mesa-git. You can see the actual bug report about it here.
Hopefully with this patch landed, it means more people can enjoy another highly rated Linux-native game on open source drivers. It might still need other hacks to run, as previously it needed more than one change.
While this is only changing a config file to have this game-specific change in by default, it's still nice that users don't have to look up what to do to get it working.
I cannot test it personally, as I don't have an AMD card to test with. Article taken from GamingOnLinux.com.
Just today a commit was sent in to Mesa which mentioned "drirc: Allow extension midshader for Divinity: Original Sin (EE)". It's interesting to see game-specific changes like this, as some games will sadly need them.
You can see the commit here, which has already landed in Mesa-git. You can see the actual bug report about it here.
Hopefully with this patch landed, it means more people can enjoy another highly rated Linux-native game on open source drivers. It might still need other hacks to run, as previously it needed more than one change.
While this is only changing a config file to have this game-specific change in by default, it's still nice that users don't have to look up what to do to get it working.
I cannot test it personally, as I don't have an AMD card to test with. Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
I also recommend setting this for the game, otherwise it will clutter your $HOME:
HOME=${HOME}/.local/share
Where should I set this?
Last edited by Al3s on 8 January 2017 at 3:19 pm UTC
0 Likes
I often poke fun at people on Twitter, and it wasn't a direct quote just inspired by stuff here. The point again remains, people saying how it's not a big deal. Well to people who have no idea about this, it will be.The end result is the same, users don't have to fuss around and search around for solutions.I agree. Let's hope Larian makes the next step which renders this hack unnecessary.
Edit: About unnecessary things – was it really necessary to drag this discussion to Twitter and even change my message by cherry-picking and ignoring the term "IMHO"? :|
1 Likes, Who?
I just hope Linux drivers (*) will never get bloated with some optimal render paths for certain games, because that's just putting the cart before the horse.
Either game devs learn to fucking programming, or there fucking games should never be published/released.
Same nonsense as with browser-crap. Just because every idiot thinks he knows how to write html (who actually doesn't) suddenly browsers had to implement tens of thousands workarounds. Well "had to", one idiot started with that shit and then everyone had to.
It's idiotic. Learn the goddamn api. Not talking about some settings obviously. They are specific and I agree that stuff can go in there. But generally speaking, I don't want huge drivers just because of incompetent devs.
(*) I mean the mesa/open source ones, obviously. I don't care for any shit nvidia or amd put in their proprietary nonsense.
Either game devs learn to fucking programming, or there fucking games should never be published/released.
Same nonsense as with browser-crap. Just because every idiot thinks he knows how to write html (who actually doesn't) suddenly browsers had to implement tens of thousands workarounds. Well "had to", one idiot started with that shit and then everyone had to.
It's idiotic. Learn the goddamn api. Not talking about some settings obviously. They are specific and I agree that stuff can go in there. But generally speaking, I don't want huge drivers just because of incompetent devs.
(*) I mean the mesa/open source ones, obviously. I don't care for any shit nvidia or amd put in their proprietary nonsense.
0 Likes
I also recommend setting this for the game, otherwise it will clutter your $HOME:
HOME=${HOME}/.local/share
Where should I set this?
In the same script that you set workaround hacks. I.e. in runner.sh that comes with the game.
1 Likes, Who?
Shugyousha Jan 8, 2017
The git version of mesa I am running on my machine (the GPU is a RX480) includes this patch already. I tried running that game from Steam directly (without the hacks that work) and while it opened a window and drew the custom cursor (which it didn't do before that patch) it also froze my whole machine.
The patch only gets the game half-way there and I assume they will have to add another workaround before the game runs without issues.
Last edited by Shugyousha on 8 January 2017 at 6:43 pm UTC
The patch only gets the game half-way there and I assume they will have to add another workaround before the game runs without issues.
Last edited by Shugyousha on 8 January 2017 at 6:43 pm UTC
0 Likes
The patch only gets the game half-way there and I assume they will have to add another workaround before the game runs without issues.
They already stated, that it's a mistake in the game to read some hardcoded vendor string for AMD. Mesa isn't going to "fix" it for them. May be instead of making shims they'll provide some way to set that through environment variables. At least that won't require compilation.
Last edited by Shmerl on 8 January 2017 at 6:52 pm UTC
0 Likes
I hope in a year all games will run with mesa. Realistic? You would have much more choice with the graphics cards. I think AMD is bringing some interesting cards to the market this year.
Last edited by 1xok on 8 January 2017 at 10:46 pm UTC
Last edited by 1xok on 8 January 2017 at 10:46 pm UTC
0 Likes
I also recommend setting this for the game, otherwise it will clutter your $HOME:
HOME=${HOME}/.local/share
Where should I set this?
In the same script that you set workaround hacks. I.e. in runner.sh that comes with the game.
Thanks. I'll give it a try tomorrow.
0 Likes
I also recommend setting this for the game, otherwise it will clutter your $HOME:
HOME=${HOME}/.local/share
Where should I set this?
In the same script that you set workaround hacks. I.e. in runner.sh that comes with the game.
Or in the steam launch options:
HOME=${HOME}/.local/share %command%This is actually a pretty good idea, and I am considering changing this variable before launching Steam, considering the number of games that behave correctly.
0 Likes
While it's good that more and more games will run on Mesa without users having to do a lot of fiddling, I certainly hope that this doesn't become the norm. I don't really like the idea of Mesa becoming a mess of exception cases and strange code paths for all the weird things game developers do when they don't really know what they are doing.
2 Likes, Who?
While it's good that more and more games will run on Mesa without users having to do a lot of fiddling, I certainly hope that this doesn't become the norm. I don't really like the idea of Mesa becoming a mess of exception cases and strange code paths for all the weird things game developers do when they don't really know what they are doing.As was mentioned, this is purely a config change. No new code paths so we're not quite there yet. Also the mechanism is generic enough to be usable for debugging and other problematic titles. Wouldn't have been accepted otherwise.
I can't honestly argue that this isn't a hack though and it will stop working if the executable is renamed.
0 Likes
Yeah I don't really get the people saying it's not a hack. A special config for it is essentially a specific-game hack.While it's good that more and more games will run on Mesa without users having to do a lot of fiddling, I certainly hope that this doesn't become the norm. I don't really like the idea of Mesa becoming a mess of exception cases and strange code paths for all the weird things game developers do when they don't really know what they are doing.As was mentioned, this is purely a config change. No new code paths so we're not quite there yet. Also the mechanism is generic enough to be usable for debugging and other problematic titles. Wouldn't have been accepted otherwise.
I can't honestly argue that this isn't a hack though and it will stop working if the executable is renamed.
1 Likes, Who?
Or in the steam launch options:
HOME=${HOME}/.local/share %command%
This is actually a pretty good idea, and I am considering changing this variable before launching Steam, considering the number of games that behave correctly.
In case of GOG release that would be start.sh, but I don't think it's a good idea to set it for every game, since some do follow XDG base directory spec correctly, and for those you don't want to do it. So setting it individually only for games which mess up $HOME directly is the best approach.
Last edited by Shmerl on 9 January 2017 at 4:32 pm UTC
1 Likes, Who?
Or in the steam launch options:
HOME=${HOME}/.local/share %command%
This is actually a pretty good idea, and I am considering changing this variable before launching Steam, considering the number of games that behave correctly.
In case of GOG release that would be start.sh, but I don't think it's a good idea to set it for every game, since some do follow XDG base directory spec correctly, and for those you don't want to do it. So setting it individually only for games which mess up $HOME directly is the best approach.
Well, for those that follow the XDG spec correctly, that would be $XDG_DATA_HOME anyway :)
Even Steam puts a .steam folder in my home folder...
But yeah, the ideal wold be for Valve to enforce this behaviour.
0 Likes
Even Steam puts a .steam folder in my home folder...
I see. Then it's already a mess, and doing it for the client can help with moving client data to proper place, but it can also mess up games which check if $XDG_DATA_HOME isn't set, and use $HOME/.local/share when it's not. For those you'll get: $HOME/.local/share/.local/share in result.
But yeah, the ideal wold be for Valve to enforce this behaviour.
It's really up to individual games to follow the spec. Valve should fix their own client though.
Last edited by Shmerl on 9 January 2017 at 4:51 pm UTC
0 Likes
Even Steam puts a .steam folder in my home folder...
I see. Then it's already a mess, and doing it for the client can help with moving client data to proper place, but it can also mess up games which check if $XDG_DATA_HOME isn't set, and use $HOME/.local/share when it's not. For those you'll get: $HOME/.local/share/.local/share in result.
I completely agree, but why wouldn't it be set? It is set on my system, and if you change $HOME to point to the XDG_DATA_HOME location, it would be a shame not to ensure that the other variable is set on the system ;)
That's a point I do not agree on. In my opinion, Valve has a spec they enforce on games, just like their target platforms have a spec. Games with missing executables Should not be distributed; and I think it should be the same for these folders. Automated testing should ensure both.But yeah, the ideal wold be for Valve to enforce this behaviour.
It's really up to individual games to follow the spec. Valve should fix their own client though.
That said, sandboxing might be a solution in the long run.
Edit: or a collection of game profiles to Taylor the environment variables to the game, but I am too lazy to compile such a list.
Last edited by MayeulC on 9 January 2017 at 5:06 pm UTC
0 Likes
Valve have no control over how games store configuration. And games shouldn't rely on such control either. It will only complicate ability to release games without Steam.
0 Likes
Valve have no control over how games store configuration. And games shouldn't rely on such control either. It will only complicate ability to release games without Steam.Valve have quite a lot of control over games sold on their service. They're important enough that devs are willing to work to get their games on Steam.
In any case, I don't see the harm in them requiring adherence to standard practices, like the XDG directory spec. I don't think they would though, although they already recommend the spec and have automation/helper tools in their SteamOS SDK.
0 Likes
cRaZy-bisCuiT Jan 9, 2017
Just to clarify:Thank you very much! The game runs very fine now! Is there a way to make the game starting directly from Steam with the Hack applied? Obviously the Multiplayer won't work like this.
You can play Divinity: Original Sin right now with stable Mesa, and you don't need any patches to mesa to get it running.
[...]
Last edited by cRaZy-bisCuiT on 9 January 2017 at 7:32 pm UTC
0 Likes
Patreon
PayPal
See more from me