It's time to bug Feral Interactive about future port requests once again

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.

Not huge, because another is not translating the entire OS unlike what you say. Wrappers like Wine don't emulate the whole Windows kernel for instance. They simply translate a given list of calls into ones that provide similar functionality through native means. It's far from providing entire OS at runtime. That's why for instance Wine won't work for Windows hardware drivers as far as I know.

So the difference between static and dynamic translation is purely nominal. The result is simply a chain of calls into native functions. Wine naturally should implement Windows calling mechanism I suppose, to actually be able to translate Windows binary calls. Source wrappers don't need that.

What you are describing on the other hand, is already something like ReactOS which indeed provides a whole Windows like operating system. Wine is nowhere aiming at such functionality.


Last edited by Shmerl on 28 January 2018 at 10:12 pm UTC

Note that a wrapper isn't "translating", it's putting actual native code into non natively "named" function calls

That is translation already. Not translating means you call right functions to begin with, using the design of the native API, instead of hacking around one API into completely different one.

One is native, the other is non-native.

Sorry, but source translation is nowhere a native approach. It's a translation hack. Which is a great shortcut of course, but it's not what you'd call a proper software design from the ground up.


Last edited by Shmerl on 28 January 2018 at 10:15 pm UTC

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


Last edited by natewardawg on 28 January 2018 at 10:33 pm UTC

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

It is normally called static translation on the source level, or compile time translation. The main point why it's not native is not the formality of names, but the fact that you take one API with its own design, and fit it into another API with a different design. The 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.


Last edited by Shmerl on 28 January 2018 at 10:37 pm UTC

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


Last edited by natewardawg on 28 January 2018 at 11:44 pm UTC

By your own definition of what translation is, there's no such thing

It's not a new thing translating one API into anther. You can say "there is no such thing", but it's not really uncommon.

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 make it native, it should be designed with native API as a target. And not retrofitted post factum by wrapping foreign API into native one (no matter on what level). That's about it. And as above, I have no problem with non native ports.


Last edited by Shmerl on 29 January 2018 at 1:03 am UTC

I'm actually curious about why it seems to matter. What does "fully native" give that a source or runtime based wrapper does not? I think performance is not really that much of a problem; while a "fully native" game would likely have better performance, that only comes from inclusion during game development and engine design rather than any compiler magic.

If performance isn't a problem, then it doens't matter much, except from design cleanness perspective. But performance isn't always an easy target. Consider for example performance hit that The Witcher 3 gets in Wine, because of translation of D3D11 into OpenGL 4.x.

I.e. it's still pretty playable, but there is a performance hit that you need to take in account for given hardware.

That's what translation here is. It's not just simply taking shaders and translating them. It's trying to map completely different API with its own logic, into another one with its own restrictions. That's a logical translation. It's probably easier to make it efficient if you are translating it into low level Vulkan.


Last edited by Shmerl on 29 January 2018 at 1:09 am UTC

The Elder Scrolls Online
DOOM 2016
Star Wars Battlefront 2


Last edited by Krogash86 on 29 January 2018 at 10:35 am UTC

To make it native, it should be designed with native API as a target. And not retrofitted post factum by wrapping foreign API into native one (no matter on what level). That's about it. And as above, I have no problem with non native ports.

You seem to have a different notion of what "native" binary means in this case.
I'm using "native" binary as "every part of it is compiled for the target system", Linux in this case.
This is what Feral does and VP doesn't do.
VP makes Windows binaries run on Linux.
(And this adds complexity to an already complex topic.)
If that difference doesn't matter for you, it's fine, but that doesn't stop it from being a difference.

Of course, having it so native that everything in it is specifically targeted at the Linux environment would be even better.

I don't focus just on the binary, but on the source level as well. That's the difference in how I view non native result. In the end, you get a binary that runs on Linux either way, because we aren't talking about VMs here.

So in this sense, Feral's ports aren't native either, because they wrap foreign API in their code into native one.


Last edited by Shmerl on 29 January 2018 at 1:55 pm UTC

What I want from a Linux port of a game:
1. To see it when I launch the Linux Steam client;
2. To be able to click "install" there to get it downloaded;
3. To play it with not-so-bad performance;
4. To have controller support if possible.

The rest doesn't matter for me.

AFAIK, source code for Saints Row 1&2 was lost, so VP port is the best what we could have on Linux for SR. It's either this, or nothing. Would nothing be better?

AFAIK, source code for Saints Row 1&2 was lost, so VP port is the best what we could have on Linux for SR. It's either this, or nothing. Would nothing be better?

My humble opinion is that binary wrapping is fine for old games, where the source might be lost and porting would probably not be worth the work anyway, but - for me - not for current games.

So, how many years old must be games to be considered old enough for wrapping?

So, how many years old must be games to be considered old enough for wrapping?

I calculated exacty 3.14 years.

Seriously, though: Why you're asking?

What I want from a Linux port of a game:
1. To see it when I launch the Linux Steam client;
2. To be able to click "install" there to get it downloaded;
3. To play it with not-so-bad performance;
4. To have controller support if possible.

The rest doesn't matter for me.

AFAIK, source code for Saints Row 1&2 was lost, so VP port is the best what we could have on Linux for SR. It's either this, or nothing. Would nothing be better?

Between binary wrapping and nothing I'll take my nothing please.

Horizon Zero Dawn.

It's gotten great reviews and the game looks awesome, looks fun and I really want to play it. It's said to have an engaging story and have side quests that feel a lot more interesting and meaningful than those is usual in open world games.

Also, awesome robot animals!

Not an entirely sensible suggestion. It is Sony's game on Sony's hardware. Maybe if one day it gets released on XBOX, Windows, then it becomes something that could be considered.

Meanwhile, I notice a lot of these suggestions to Feral are for existing games. There are a lot of upcoming games, which people will be wanting on Linux as soon as they're released.

Games such as these:

Kingdom Come: Deliverance
Monster Hunter: World
Sea of Thieves
A Way Out
Far Cry 5
Metal Gear: Survive
Vampyr
Metro Exodus
Skull and Bones
Call of Cthulhu
Anthem
Mount & Blade 2: Bannerlord

Ok, Sony are the evil bastards that unleashed Blueray and made every damn movie released on the medium encrypted with DRM.

The triple A indy game, Hellblade: Sinua's sacrifice, it is then. That's my one game port wish.

Hellblade: Sinua's sacrifice is a single player game that if you are to believe Jim Sterling truly elevates "triple A" game making to art.
This game needs to come to Linux. Extremely beautiful and an experience I really want to try.


Last edited by AlveKatt on 30 January 2018 at 9:21 am UTC

Horizon Zero Dawn.

It's gotten great reviews and the game looks awesome, looks fun and I really want to play it. It's said to have an engaging story and have side quests that feel a lot more interesting and meaningful than those is usual in open world games.

Also, awesome robot animals!

Not an entirely sensible suggestion. It is Sony's game on Sony's hardware. Maybe if one day it gets released on XBOX, Windows, then it becomes something that could be considered.

Meanwhile, I notice a lot of these suggestions to Feral are for existing games. There are a lot of upcoming games, which people will be wanting on Linux as soon as they're released.

Games such as these:

Kingdom Come: Deliverance
Monster Hunter: World
Sea of Thieves
A Way Out
Far Cry 5
Metal Gear: Survive
Vampyr
Metro Exodus
Skull and Bones
Call of Cthulhu
Anthem
Mount & Blade 2: Bannerlord

Ok, Sony are the evil bastards that unleashed Blueray and made every damn movie released on the medium encrypted with DRM.

The triple A indy game, Hellblade: Sinua's sacrifice, it is then. That's my one game port wish.

Hellblade: Sinua's sacrifice is a single player game that if you are to believe Jim Sterling truly elevates "triple A" game making to art.
This game needs to come to Linux. Extremely beautiful and an experience I really want to try.

Hellblade is cool. I should finish it.

@everyone arguing the semantics of "native".
Wine is fine, but it isn't native. Even just the Wine API wrapper, let alone the full Wine system, has a certain amount of added system resource overhead you wouldn't, per se, have were the software written directly targeting the native interfaces. That said, unless you're the kind of idealist who absolutely adheres to Stallman's and the FSF's philosophy (at which point even DOSBox and other emulators are questionable), there is little else that meaningfully suggests against their use when they at least provide a way for us on Linux to demonstrate demand. Once the bigger releases are regularly targeting our platform, there's more room for us to then point out that developing targeting Linux from the ground up is going to reduce porting costs (no need to get a different team up to speed on the code base then make the requisite refactorizations to get the software running on a new system) and that day one native support will ensure more Linux purchases during that critical initial release window at full price and even preorders and the like should enough community good will be garnered.

@everyone arguing the semantics of "native".
Wine is fine, but it isn't native. Even just the Wine API wrapper, let alone the full Wine system, has a certain amount of added system resource overhead you wouldn't, per se, have were the software written directly targeting the native interfaces. That said, unless you're the kind of idealist who absolutely adheres to Stallman's and the FSF's philosophy (at which point even DOSBox and other emulators are questionable), there is little else that meaningfully suggests against their use when they at least provide a way for us on Linux to demonstrate demand. Once the bigger releases are regularly targeting our platform, there's more room for us to then point out that developing targeting Linux from the ground up is going to reduce porting costs (no need to get a different team up to speed on the code base then make the requisite refactorizations to get the software running on a new system) and that day one native support will ensure more Linux purchases during that critical initial release window at full price and even preorders and the like should enough community good will be garnered.

Except they don't demonstrate demand...all stats collected will show wine users as Windows users. The only way they know we're on wine is if we tell them at which point just tell them we want a Linux version.

I just read that Dragon Ball FighterZ is developped under Unreal Engine, that's a game I'd like to have on Linux !