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

Quoting: Eike

Quoting: ScooptaAlthough Feral does seem to put quite a bit of work into their ports I would like more info on exactly how much wrapping vs porting they're doing.

VP and WINE are doing binary wrapping, while Feral is doing source wrapping. The first runs Windows binaries in Linux, the second creates pure ("native" ) Linux binaries. Do we need way more information?

Binary or source, it's still wrapping. One isn't much better than another. So if someone objects to wrapping in general, there shouldn't be a difference to what wrapping. I don't object to it. Wrapping simply is cheaper than proper rewrite, that's why many resort to it. Surely, a proper native version is always the best way to do it, but it can be also the most expensive.


Last edited by Shmerl on 28 January 2018 at 7:45 pm UTC

My Top Picks:

1. Path of Exile

2. Diablo 2: Lord of Destruction

3. The Elder Scrolls IV: Oblivion

4. Grand Theft Auto V

5. Crysis


Linux native of course, I could care less about Mac OS or Mobile.

Maybe all Deus Ex games also. Including Invisible War, not the greatest but still needed for the set.


Last edited by stud68 on 28 January 2018 at 8:01 pm UTC

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.

Quoting: DragunovMy Top Picks:

1. Path of Exile

2. Diablo 2: Lord of Destruction

3. The Elder Scrolls IV: Oblivion

4. Grand Theft Auto V

5. Crysis


Linux native of course, I could care less about Mac OS or Mobile.

If I'm being honest I'd much rather have Skyrim special edition than Oblivion but Oblivion is my least favorite elder scrolls and we already have Morrowind.

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.

If it runs in the end with acceptable performance, I don't see how it matters. And they are both not native. If you are a purist from development perspective, you can't say one is OK while other is not. It's still translating calls (statically or dynamically).

And, as a Linux user I'd even say the opposite - FOSS dynamic translation is already better than static closed one, just because it's FOSS (as long at they are comparable performance wise of course).


Last edited by Shmerl on 28 January 2018 at 9:40 pm UTC

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.

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


Last edited by natewardawg on 28 January 2018 at 9:41 pm UTC

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.

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

Same thing happens dynamically, except calls are translated at runtime. Even at source level, the wrapper needs to retrofit completely foreign API into another one that is native. It's a hack, not a proper software design to begin with. But as long as it produces a working result cheaper, some don't care if it's a hack.


Last edited by Shmerl on 28 January 2018 at 9:47 pm UTC

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.


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