Confused on Steam Play and Proton? Be sure to check out our guide.
Latest Comments by Creak
SC Controller driver and UI version 0.4.5 is out, last release for a while
23 September 2018 at 1:17 pm UTC Likes: 24

I don't understand... How can we be against this Code of Conduct? Having one is having a political movement?

I might have missed something at some point in the Linux news.

Transhuman Design has removed the Linux version of BUTCHER due to issues in favour of Steam Play (updated)
22 September 2018 at 2:42 pm UTC

Quoting: Hamish
Quoting: CreakOn the other hand, Linux changed a lot in the recent years in becoming a more mature gaming platform. But the differences between 3 years ago and now are still huge (which is great!), but it doesn't help when you try to support this platform.

Can I have some elaboration on this? I am not saying it is not true, but from where I am standing, I have not seen much change in the last five years to how my setup functions. I have been in a fairly sweet spot for awhile now. Granted, five years ago is about as long as it has been since I have changed my hardware.
Disclaimer: I don't know exactly how it went, I'm speculating simply based on my coding experience.

Imagine the devs at Unity making their engine to run on Linux somewhere around 2015-2016. At the time, a bunch of OpenGL features weren't implemented in the drivers, Mesa got just about OpenGL 4.0, Vulkan wasn't even a thing on Mesa, and there wasn't as many games as today to test these drivers in the field.

And they couldn't base their code only on the very latest drivers, since it doesn't represent the vast majority of the devices Unity is being run on. So they had to compromise to have the best balance between stability and bleeding-edgeness.

3 years forward: we have OpenGL 4.5 on Mesa and 4.6 on NVIDIA, we have more and more AAA games, there's been hundreds (thousands?) of bug fixes in the Mesa drivers, X11 received at lot of fixes as well and a bunch of additional improvements when dealing with GPUs, Wayland is more and more a thing, ...

My point: Unity 5.6 on Linux might be outdated by all these improvements.

On the other hand, Windows 10 was already a thing in 2015, developers could already play with Vulkan at its release in 2016, and, apart from Vulkan, the drivers didn't evolved that much in 3 years. So Unity 5.6 on Windows is still more likely to work well, it's just a bit old.

Edit: typos, rewording

Transhuman Design has removed the Linux version of BUTCHER due to issues in favour of Steam Play (updated)
21 September 2018 at 1:05 pm UTC

Quoting: 3qET7rL9BdThis decision by the developer confuses me a lot.

How many Linux versions of the game have they sold? Judging by the comments here they have sold at least one. What if this was a game sold for Xbox and Playstation but it turns out the Xbox version doesn't work would it then be acceptable if the developer just dropped support for the Xbox version? I assume the developer legally have to make sure that the product they sold actually works otherwise offer refunds?

I would equivalent this with a car manufacturer finding a manufacturing error in one of their cars and issuing a full recall of all sold units meaning a full refund for everyone who bought it.

Since they they have asked Valve to whitelist the game using Proton I assume they've spent hours and hours and hours testing the game with Proton and knows the game works flawlessly with it? Right? Right? For some reason I highly doubt it mostly because the developer themselves say "and hopefully enjoy your game working on Linux again" which means they don't even know if it works with Proton.

Sigh.

I hope Valve gives them a proper response for asking them to whitelist a game they don't even now works with Proton.

I'm also guessing since the sole programmer is no longer available any bugs found in the Windows version due to them using an old version of Unity for any other reason will also go unfixed. One the one hand I guess you can't expect developers to update games after release. What you see is what you get. But what if you find a game breaking bug? I really think you should be able to expect the developer to fix problems preventing you from playing the game from start to finish.

In the end we weren't the ones deciding what platforms to release the game on, the developers did. If they now have found that the version of Unity they are using has a lot of issues on Linux and therefore decided to stop selling the game on Linux shouldn't they have found this when performing their own testing before releasing the game? To me it just seams like the developer clicked "export for Linux" without doing any sort of testing and hoped for the best. I appreciate they trying to bring their game to Linux but I do think we should be able to expect a little bit more from developers.

You can't compare with the console market that easily. Before releasing on console you have to be approved by the manufacturer, and also the hardware doesn't change: the Xbox will stay the same XBox (or the manufacturer will provide retro-compatible updates, e.g. PS4 and PS4 Pro, Xbox One and Xbox One S).

And for the comparison with cars, well, a buggy game doesn't kill people.

On the other hand, Linux changed a lot in the recent years in becoming a more mature gaming platform. But the differences between 3 years ago and now are still huge (which is great!), but it doesn't help when you try to support this platform. In that matter, Windows is a way more stable platform (less than a console, but more than Linux) -- To be clear: I don't mean that Windows crashes less than Linux, but that a binary on Windows will require less work to continue working than a binary on Linux, because everything is more mature for the gaming scene there.

I don't think Transhuman Design would have decided to make a fix if Steam Play wasn't available. They would simply have stopped supporting Linux, like several devs have done before in the same situation.

The ROI to support Linux at the moment is simply not big enough. Steam Play will help gather more Linux gamers, which will help to create momentum, which will help to see Linux as a more and more legitimate gaming platform.

Transhuman Design has removed the Linux version of BUTCHER due to issues in favour of Steam Play (updated)
21 September 2018 at 1:12 am UTC

Quoting: liamdaweI'm pretty curious to know what the actual issue is here. Is it Unity once again messing up in their older builds, is it a driver update that broke it? We know so little.
I don't know what is the real reason, but if I had to guess, I would say that Unity 5.6 is quite old (released in late 2016) and the state of the graphics drivers then, although much better than 10 years ago, was way inferior to what it is today. While on the other hand, the graphics drivers on Windows are pretty stable since the last 2 years.

So I would not be surprised if games still running under Unity 5.6 would start to see some issues on latest Linux distributions.

Valve have hired another developer to upstream SteamOS driver changes, including Xbox One S rumble support
12 August 2018 at 3:56 pm UTC Likes: 1

Quoting: mylka
Quoting: GuestI simply love it to see Valve so dedicated to Linux.

but why arent they make new games, or just be publisher for games.
They are actually ;)
Gaben said they are working on several games, two of which are already announced: In the Valley of Gods and Artifact. The other projects haven't been announced yet.

Looks like Valve may be preparing a 64bit version of the Steam client
10 August 2018 at 1:26 pm UTC Likes: 1

The memory argument always come back in a 32 vs 64-bit discussion, but as many pointed out, it's just a limit for one process -- which can indeed be bypassed by PAE, but Linux devs would like to remove this "hack" as soon as possible because it's a reason for a lot of issues. ("the only real major failure of the x86 is the PAE crud" -- Linus Torvald

But the real main point of going full 64-bit is that all the 64-bit CPUs have a better common base of instructions, and have more registers, allowing to do some optimizations directly at compile time. It also remove a bunch of obsolete x86 extensions.

If the same program can run on a very old Pentium as well as on the latest 32-bit CPU, it is because the x86 architecture is a huge pile of extensions, so that it is always compatible. But the way it works is that for each instruction the CPU receives, it look for it through its several layers of instructions, starting from the very basic 386 instruction set layer and up to the latest AVX-512 instruction set layer. And, as much as compatibility is a good thing, in the case of a CPU there are so many extensions that it was slowing down the whole execution. See X86-64#Architectural_features.

In the case of the Steam GUI, I'm not sure this is going to change a lot of thing but it's true that it's a step into the right direction since 32-bit CPUs are going instinct now -- and I sure hope that Steam won't take more than 4GB of RAM :D

But for the case of games (which is not linked at all to Steam going 64-bit), the access to SSE and SSE2 instruction set and more registers by default can have a real impact on the games perfs.

Indie FPS 'Ballistic Overkill' updated with a new 'Rounds' game mode
6 August 2018 at 12:50 pm UTC

Saw you play the game on twitch Liam, a few months ago, and decided to buy the game, but the game would not launch (but I don't have a standard rig, so I don't blame the devs). I think I'll give it another go anyway, this seems like a very good FPS! :D

The video of Keith Packard's presentation on 'Making Games Work Better on Debian' is up
31 July 2018 at 8:18 pm UTC

Very interesting! And I hope we'll see these "fast paths" for non-VR rendering soon ;)

The CTO of Croteam has written up a post about 'The Elusive Frame Timing'
26 July 2018 at 3:22 pm UTC Likes: 1

@raneon it could actually. that's probably not the only reason, but it's possible that the GPU drops a frame because the display isn't ready yet for the next frame. And the result is, if you disabled V-Sync, you'll get tearing, and if you enabled V-Sync, you'll get stuttering (no perfect solution).

I personally prefer enabling V-Sync since I prefer a small stuttering than a sliced image (in other words, I prefer a strong 30 fps than an irregular and out-of-sync 45 fps).

And that's where Freesync (or G-Sync for NVIDIA customers) comes to play. The display will show the image that the GPU sends, with a much loose consideration for the frame rate, since the display frame rate is now dynamic and the GPU can send its rendering within a frame rate range and not at a unique frame rate.