Quoting: 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? :D

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. :)

View this comment - View article - View full comments

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.

View this comment - View article - View full comments

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 [External Link]

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.

View this comment - View article - View full comments

Quoting: 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 :)

View this comment - View article - View full comments

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 :D

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: 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.

View this comment - View article - View full comments

Quoting: Eike

Quoting: 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 [External Link].

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. :)

View this comment - View article - View full comments

Although they aren't working rigorously on it, it's always nice to see Valve hasn't abandoned SteamOS :)

View this comment - View article - View full comments

My choices are Rise of the Tomb Raider and Final Fantasy XII, which should be available on Steam at the beginning of February :)

View this comment - View article - View full comments

Quoting: razing32The engine looks amazing.
Have to admire the guy's passion despite being offered recruitment from other major engine companies.
Now ... if only I wasn't so inept at coding to actually be able to use it.

They do have visual scripting now :)

View this comment - View article - View full comments