You can sign up to get a daily email of our articles, see the Mailing List page!
Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can support us on Paypal and Liberapay!
Latest Comments by natewardawg
Playing Prey on Linux in 2018
14 February 2018 at 10:42 pm UTC

I played this game back in 2007/2008 or so and I installed it and starting playing it again a few months back. It's a very fun and ingenuitive game IMO.

Rise of the Tomb Raider announced for Linux, port from Feral Interactive
13 February 2018 at 2:00 pm UTC Likes: 1

MarkyWoohoo!

EhvisNow I'm curious. IIRC, RoTR has DX12 support. Did Feral use that basis for their port to Vulkan or did they go for DX11 translation they already had working.
I'd like to know too. Would be interesting to know which is better/easier for Feral.
Is the DX12 version better than DX11 on windows?

If they never state otherwise, I'm quite sure this will be obvious once the benchmarks start rolling in

Valve has boosted their Linux ranks by hiring another developer to work on open source graphics
9 February 2018 at 11:12 pm UTC Likes: 1

SamsaiSeriously, take the Wine talk to the forum. If this mess of a comment section keeps spiralling out of control further I'll have to close it.

Agreed, haha, why are Wine, Feral ports and different wrappers being discussed on an article about Valve hiring a graphics driver engineer?

Mesa development affects every kind of port, but also helps people who do video editing, 3D content creation, and even helps people who just want to watch a movie through a player with GPU acceleration. I think it's awesome what Valve is doing and it will likely affect more than just games.

Valve has boosted their Linux ranks by hiring another developer to work on open source graphics
8 February 2018 at 3:53 pm UTC Likes: 4

I still believe Valve is playing the long game with quite a bit of patience. Linux is the best hedge Valve seems to have and I don't see them abandoning it unless it falls off a cliff... which is highly unlikely at this point.

Windows 10 S might alarm Valve into boosting SteamOS again
5 February 2018 at 12:36 pm UTC Likes: 2

Windows 10 S mode seems like a small issue... when compared with the upcoming Windows Polaris. (edit: Which *cannot* be upgraded at all)

https://www.windowscentral.com/understanding-windows-core-os-and-polaris

But yep, I hope this lights a fire under Valve to make a huge push for Linux Maybe it's just me, but it does seem like they've been making more updates to Steam OS lately than usual.

It's time to bug Feral Interactive about future port requests once again
28 January 2018 at 11:44 pm UTC Likes: 3

ShmerlThe mere fact of doing that is a translation. You can debate the benefits or downsides of static translation vs dynamic one, but they both remain non native approaches.

By your own definition of what translation is, there's no such thing, and can never be any such thing as a "Native Port", because a "Port" implies something had to be "translated" from one OS to another. The phrase "Native Port" simply implies the game was "compiled" on and for Linux. That's it! The only "approach" you can take where nothing will be "translated" is to design the game for Linux from the beginning, in which case it's no longer a "Port", therefore can't possibly be a "Native Port".

If you disagree, I have one simple question: How much non native game design and/or code can be present in order to call it a "Native Port"?

To top that off, this wasn't even my original argument to start with, it was that WINE running a Windows EXE and a "Native Port" with a few wrapped calls are completely different... which you haven't addressed, at all!

1. WINE is like transmutating Fruity Pebbles into Cheerios.
2. A wrapper within a "Native Port" is like pouring Cheerios into a Fruity Pebbles Box.
100% different

Please address how these two things are even remotely similar

Now I'm done

It's time to bug Feral Interactive about future port requests once again
28 January 2018 at 10:32 pm UTC Likes: 3

Calling wrapped libraries "translating" is like pouring cheerios into a Fruity Pebbles box and calling it transmutation. No, you're just making it look like it's Fruity Pebbles when it's actually Cheerios. You're "wrapping" it in a different box.

I've written wrappers before, calling them translating is a huge misstatement.

For instance, right now I'm writing a wrapper for Godot that wraps the UnityEngine namespace. It contains 100% compatible Godot code. It's just that I don't have to re-learn (or re-write) certain things when using it or bringing a project over from Unity.

For instance, in Unity I use the WWW class:

WWW www = new WWW("https://www.gamingonlinux.com"); // Internally calls Unity engine code

and in Godot I use the exact same line of code with my wrapper...

WWW www = new WWW("https://www.gamingonlinux.com"); // Internally calls Godot engine code

This isn't translating, it's using 100% Godot code, but looks (and essentially works) just like it does in Unity.

Using WINE and using wrappers are 100% different things. Again, in one you're "translating" non native code at runtime, in the other the game is 100% native code. Running DXMD in WINE is 100% Windows code and running DXMD on Linux is using 100% Linux code

Anyway, I'll stop discussing this as it's completely off topic

It's time to bug Feral Interactive about future port requests once again
28 January 2018 at 9:59 pm UTC Likes: 3

Shmerl
natewardawgI have to agree 100% here, wrapping an entire OS compatibility system is much different than adding some functions that are named the same as those of a Windows API so that it will call a non Windows one instead.

I don't see a big difference. They still need to translate calls, translate shaders and etc. Just because one is done at compile time and another at run time doesn't make first one not translate them.

The only benefit I can see here is that static translation offers more tools for correctness checking and etc. Without having the original code you have to deal with results as is.

One is using a few 100% native calls, but using non-native names in the code, the other is translating non native calls for an entire OS at runtime, it's a huge difference. One is using native code, the other is using/translating non native code.

Note that a wrapper isn't "translating", it's putting actual native code into non natively "named" function calls. Literally the only non native thing about the wrapper is that you're essentially calling OpenGL DirectX instead. WINE is translating non native code.

Or to put it into simple bullet points:

* A wrapper has 100% native code
* WINE translates non-native code at runtime

I'm all for both approaches as they are useful in different cases but these are 100% different approaches. One is native, the other is non-native.

It's time to bug Feral Interactive about future port requests once again
28 January 2018 at 9:40 pm UTC Likes: 4

Eike
ShmerlBinary or source, it's still wrapping. One isn't much better than another.

To me as a software developer as well as to me as a Linux user, that's a huge difference. Wrapping binaries on a different OS would be the very last resort if totally necessary. And it's not necessary for me in case of gaming. While wrappers for source is a common design pattern.

I have to agree 100% here, wrapping an entire OS compatibility system is much different than adding some functions that are named the same as those of a Windows API so that it will call a non Windows one instead. Depending on the API there might be a little bit more to it than that, but it's usually not too bad

I think what's missing is maybe a picture of what's going on...

Say you have a C++ code file for your engine that was originally written for Windows that renders stuff using DirectX11, it would first need a header file for it so that it knows about the DirectX calls.

// MyRenderer.cpp #include <DX11.h> MyRenderer::Render() { dx11->RenderDX11Stuff(); }

But, on Linux you won't have DirectX11 installed, so you make your own "DirectX" header file:

// DX11.h public class DX11 { public: void RenderDX11Stuff(); }

And then your cpp file that implements the "DX11" header file:

// DX11.cpp DX11::RenderDX11Stuff() { RenderOpenGLStuff(); }


So when the game goes to render DX11 stuff, your "DX11" code actually makes OpenGL calls.

This is obviously a simplified version, but should hopefully get the point across.

  Go to:
Livestreams & Videos
Community Livestreams
See more!
Popular this week
View by Category
Contact
Latest Forum Posts
Facebook