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

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

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

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

Quoting: natewardawgI'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

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


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

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

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

Quoting: GuestI'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

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