Patreon Logo Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal Logo PayPal. You can also buy games using our partner links for GOG and Humble Store.
Latest Comments by RCL
GOL Survey Results: June
7 Jul 2015 at 10:02 pm UTC Likes: 1

Please add the console question to the next polls as well. This may explain why people did not buy games on PC at all.

You could also add questions like:
- how old is your gaming PC
- is at a laptop or desktop
- do you play with a controller/gamepad or keyboard/mouse
- do you play on TV or a monitor
- do you have more than one display connected to your gaming PC
- do you use a headset or loudspeakers
- do you prefer fullscreen or windowed
- do you prefer multiplayer or single
- do you play offline

These may be actually useful for game developers.

Opinion: Why We Want Native Ports Only
5 Jul 2015 at 8:06 pm UTC Likes: 4

"with the advent of Vulkan there really should be no need for non-cross platform APIs such as DirectX or Metal, except to create vendor lock in."

Unfortunately, no. Ever heard of "design by committee"? There is a anecdote out there how two parties could not agree whether a packet length for a certain protocol should be 32 bit or 64 bit and ended up adopting 48 bit as a compromise solution.

The lack of a single powerful entity that says "stop! we're specifying it that way - and if your hardware cannot comply, too bad" was always a problem for OpenGL. Apple basically donated OpenCL to Khronos - why the heck OpenGL compute shaders were allowed to exist? I can guess that the reason was politics - some vendors did not want to support a competing GPGPU API and preferred less general approach. Now it's no wonder that Apple is pissed off and does its own thing.

Granted, OpenGL was exceptionally prone to lawyering due to its history. Arguably, it was designed with fragmentation in mind, and this fragmentation facilitated decision making akin to the above 48 bit joke - neither practical, nor satisfying for any of the parties involved. The sheer breadth of the API allowed vendors to go their own route while formally complying to the specification. Of course, this just pushed the problem to the developers who paid the real cost of the hardware compatibility, and it's no wonder that developers ran towards more "authoritarian", but also more clear and unambiguous APIs, happy to pay Microsoft for being a platform's policeman, because the price was still lower than doing it themselves.

Vulkan has better chances because the API is smaller (just a few % of the OpenGL in terms of function calls), but Khronos decision making is still a problem. Both Microsoft and Apple invite developers and vendors to discuss their upcoming API, so they are not designing it single-handedly, but they still hold the decisive voice. Khronos, on the contrary, is the European Union of the architecture boards... Let's hope they will settle on something before Metal and DX12 gain wider adoption.

Steam Replaces The Linux Tux Logo With SteamOS
27 May 2015 at 10:59 pm UTC Likes: 5

Making SteamOS a stable platform is a practical move. What constitutes "Linux" is unclear; developers need a well-defined platform (at least in terms of software, although preferably hardware as well) that they can feasibly test against. QA, especially porting QA, can be easily outnumbered by the sheer number of drivers*distro combinations alone, and then there are hardware and other peculiarities that come into play.

This is at odds with the freedom of choice that the free software is based upon, however, one can say that FOSS in general and Linux "platform" (which is in fact a family of closely related operating systems that happen to share the kernel and certain software) in particular is not geared towards mass-scale software distribution at all - even in source form, but especially so in binary. Every user is granted the ability to create their own "software soup", with this comes the responsibility for making it work.

Linux gaming community - and I am assuming commercial gaming here - should help developers reconcile this discrepancy if we want to see commercial games on our hardware. And by "helping" I mean consciously limiting the number of independent variables and accepting the fact that there are no guarantees that things work on a setup that is too different from developer's.

Divinity: Original Sin Delayed For Linux, Again
16 Nov 2014 at 1:16 am UTC

This is why UE4 supports and will continue to support cross-development, to reduce costs of making a Linux version in-house. Not a port, but version - i.e. the same code and content.

Unreal Engine 4.2 Released, Developer Tools Now On Linux
7 Jun 2014 at 9:32 pm UTC

We appreciate the attention :)

Just for the sake of clarity:
1) not all the tools can be (cross-)compiled for Linux (yet)
2) there are still a lot of bugs/rough edges even in ones that can be.

Realistically, it will take several more releases to get to the point where Linux can be used for developing UE4 games, so don't hold your breath.

However, shipping UE Linux games/demos is possible even now (developing and packaging them from Windows), and we encourage trying that for the sake of better testing.

P.S. Here are a few screenshots of UFE running on Linux (scroll down), contributed by Amigo: https://wiki.unrealengine.com/Building_On_Linux [External Link].