Slime Rancher is another Unity game to have black screen problems on Linux, here's a temp fix

How can such regressions be even released? Unity has no QA?

Unity has no QA?

Probably not so much for Linux. And this problem does not occur for everybody. I've never seen it myself.

I've seen it several times already. And it's something that should be caught by proper unit testing.


Last edited by Shmerl on 2 Mar 2018 at 2:14 pm UTC

I thought this was well known. Also, if the workaround makes the game open in a fullscreen-sized window offset from the centre, and your WM allows it, you can manually move it into position and undecorate it (maximizing can sometimes bring on the fullscreen bug). It'll play as if it were fullscreen. It's a bit of a faff, but you only have to do it once every time you play.


Last edited by Dunc on 2 Mar 2018 at 2:16 pm UTC

yup, this is something I've seen on several unity games.
Nice to see that you are posting solution... people are suffering on this. and it can be hard find answers.
I myself, besides on slime rancher, have this also for example in CHKN. just blackscreen if I run it if I have different monitor settings than before.
I run a 3 screen setup, but not always, also, on varying resolutions. so it seems to confuse lot of these games on launch.

edit: as dunc said, it's well know problem. but I hope this help to people getting things running.

.b


Last edited by tofuhead on 2 Mar 2018 at 2:45 pm UTC

If you have that bug, it's nice to use the workaround, but you also need to file a bug, or find a related bug and say you also have this problem.

It's the best way to give feedback to the unity devs

I've Seen that, too. Thanks for your help here!

It's worth mentioning that you don't have to play in windowed mode all the time - you can just launch the game in windowed mode via command line parameter to avoid the black screen and then change it to fullscreen in the game's settings. Also Solus' LSI project has a built-in workaround for this bug.

The game itself actually pops back to fullscreen mode anyway with the launch option, it's weird but it does it :)

Do we have a way of knowing which version of Unity Slime Rancher is using?
The bug is apparently fixed and released already, I'm trying to know in which release exactly.


Last edited by Creak on 5 Mar 2018 at 4:17 pm UTC

Take a look at the resource files. Unity version is usually found there in the header.

I don't have the game :/


Last edited by Creak on 5 Mar 2018 at 4:41 pm UTC

How can such regressions be even released? Unity has no QA?

I don't think this is a regression. Unity supports/releases updates for multiple versions concurrently and just looking at the major.minor version isn't enough to work out which version is older than another.

Slime Rancher is on 2017.1.0p4, which was released in August last year. The fix for the issue highlighted here didn't land in the 2017.1.x branch until 2017.1.0p5, which AFIK coincides with it being fixed in the 5.6.x branch.

IMO, if this highlights a problem at Unity's end, it's that critical issues in older engine versions aren't clearly signalled to developers prior to downloading.


Last edited by Cheeseness on 5 Mar 2018 at 11:47 pm UTC

I don't think this is a regression.

It is a bug though, which could be caught with some unit testing I suppose. Which probably means they don't have thorough unit testing in place (something like fullscreen / non fullscreen is a basic option to test).

I don't think this is a regression.

It is a bug though, which could be caught with some unit testing I suppose. Which probably means they don't have thorough unit testing in place (something like fullscreen / non fullscreen is a basic option to test).

It's definitely a bug, and everybody felt very embarrassed when it was discovered that that bug made it into release builds. The problem was resolved pretty quickly and, in my opinion, it was handled as well as it could have been. So far as I'm aware, it also resulted in improved testing practices, which is really all we can expect/ask for.

I think what Unity developers can do, is to make easily downloadable versions of their engine binaries available for everyone, with indication which ones are compatible with which (since if I remember correctly, simply replacing the binary can be enough to run some games). It would help those who bought games that aren't updated by developers anymore.


Last edited by Shmerl on 6 Mar 2018 at 2:32 am UTC

I think what Unity developers can do, is to make easily downloadable versions of their engine binaries available for everyone, with indication which ones are compatible with which (since if I remember correctly, simply replacing the binary can be enough to run some games). It would help those who bought games that arne't updated by developers anymore.

As I understand it, the engine specifically looks for data files made by the corresponding editor version so that it's not possible to mismatch engine/data versions. Given how much stuff can change between releases and how much work upgrading can be, that's pretty sensible.

Allowing users to swap in/out whatever engine version they please sounds nice, but it would also create more opportunities for QA oversights (not to mention increased support overheads for developers who couldn't be certain of what versions their users are running). A cool thought, but definitely a double edged sword.

Slime Rancher is on 2017.1.0p4, which was released in August last year. The fix for the issue highlighted here didn't land in the 2017.1.x branch until 2017.1.0p5, which AFIK coincides with it being fixed in the 5.6.x branch.

Yep, we've improved our testing and QA workflow for about a year now. When we detect a regression, we backport it to the earliest supported branch. The idea is that we don't backport a fix to a previous version until the next version is fixed. This is done in order to prevent from having a bug fixed in 2017.1 and 2017.3, but not 2017.2, which would be considered as a regression.

The "p*" releases are patched versions that contains the most recent fixes. At some point, we pack together all the patches and re-delploy a new release.

That is why a fix can be in both 5.6 and 2017.1, but the game devs still need to use the latest version of their release in order to have the latest fixes.

IMO, if this highlights a problem at Unity's end, it's that critical issues in older engine versions aren't clearly signalled to developers prior to downloading.

You're right, we do have detailed release notes for each versions, but it's very difficult to bring interest to them.

It is a bug though, which could be caught with some unit testing I suppose. Which probably means they don't have thorough unit testing in place (something like fullscreen / non fullscreen is a basic option to test).

It's not because a bug is easy to reproduce that it means it is easy to discover. We have tens of thousands of tests that runs non-stop on our build machines. When we create a feature, we also create tests for it, and each time we detect a regression, we create a test to prevent it from reappearing. But despite all that, it happens that we don't detect some bugs in time for the next release.

But as you can see from Cheeseness comment, we fixed the linux-fullscreen bug and backported it on all the supported releases. Now it is up to the game devs to make the update. If they're using 2017.1.0p4 and the fix is indeed in 2017.1.0p5, it should not be too much of a risk to upgrade their game to this release. But upgrading the engine is not an easy job as a game dev, you still need to verify that it doesn't add more regressions in your game. If they don't have QA resources (which must be the case for 99% of the indie devs), or unit tests of their own (which would not surprise me if it was also another huge majority), upgrading the engine is definitely a riskier move to make.

I think what Unity developers can do, is to make easily downloadable versions of their engine binaries available for everyone, with indication which ones are compatible with which (since if I remember correctly, simply replacing the binary can be enough to run some games). It would help those who bought games that arne't updated by developers anymore.

As I understand it, the engine specifically looks for data files made by the corresponding editor version so that it's not possible to mismatch engine/data versions. Given how much stuff can change between releases and how much work upgrading can be, that's pretty sensible.

Allowing users to swap in/out whatever engine version they please sounds nice, but it would also create more opportunities for QA oversights (not to mention increased support overheads for developers who couldn't be certain of what versions their users are running). A cool thought, but definitely a double edged sword.

Well put Cheeseness. You're totally right, both Unity devs and the game devs would not want this kind of feature. It would be way too much troubles for very little advantages. The simplest solution for everyone is still to upgrade your game to the Unity release containing your fix.


Last edited by Creak on 6 Mar 2018 at 4:02 am UTC

Well put Cheeseness. You're totally right, both Unity devs and the game devs would not want this kind of feature. It would be way too much troubles for very little advantages. The simplest solution for everyone is still to upgrade your game to the Unity release containing your fix.

Simplest, but not available if developers don't have time or will to do it. So giving users that unsupported option is not a bad thing in such case. Most will never use it, and those who would, know it's not a guaranteed method. If Unity would have been properly FOSS, it would have been doable anyway, just by the nature of the openness :)


Last edited by Shmerl on 6 Mar 2018 at 4:08 am UTC

Well put Cheeseness. You're totally right, both Unity devs and the game devs would not want this kind of feature. It would be way too much troubles for very little advantages. The simplest solution for everyone is still to upgrade your game to the Unity release containing your fix.

Simplest, but not available if developers don't have time or will to do it. So giving users that unsupported option is not a bad thing in such case. Most will never use it, and those who would, know it's not a guaranteed method. If Unity would have been properly FOSS, it would have been doable anyway, just by the nature of the openness :)

I've been helping/working with Levi (one of Unity's primary Linux developers) to identify and resolve issues with Unity's Linux player for years and have had the opportunity to witness this first hand. For a variety of reasons (some more valid than others), many developers are unwilling to upgrade.

As a proponent of Free Software and a Free Software developer, I love the idea of getting rid of the distinction between users and developers. As someone who also exists within the proprietary world, I can see that if we end up in a situation where proprietary developers can be sell a Linux game and then leave it up to Linux users to solve their own problems, the long term impact of that would be that we wouldn't get any actual support :(

It's not a nice situation either way, but I think this is just the nature of the proprietary world. The best thing we can do is focus on rewarding/supporting developers who support us properly and report bugs/work with/make note of those that don't (FWIW, I've shot information through to the developers of Slime Rancher with details on the issue and its resolution).

IMO, if this highlights a problem at Unity's end, it's that critical issues in older engine versions aren't clearly signalled to developers prior to downloading.

You're right, we do have detailed release notes for each versions, but it's very difficult to bring interest to them.

It's bigger than this though. That focuses on what's fixed in each patch release, and doesn't make note known critical issues that have/have not been resolved in future patch releases. If I could point a developer to a list like that, I think I'd have an easier time convincing them of the value of upgrading.


Last edited by Cheeseness on 6 Mar 2018 at 8:09 am UTC

@Cheeseness: Maybe you could use the issue tracker? Once a bug is reported, it appears in our issue tracker.
Here is an example of a fixed issue in the issue tracker. If you see that it is missing some information, you can still ask the devs to fill out some information in the tracked issue.

The idea would be that thanks to the issue tracker, you would be able to give one single URL to the devs you're in contact with, and they would be able to follow this exact bug.


Last edited by Creak on 6 Mar 2018 at 2:42 pm UTC