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?

Exactly.

Quoting: ScooptaYeah I'm not a huge fan of wrapping in general but all the porting companies do it to a certain extent because it's the only economical way to do it. As a result I try to minimize the games I buy from them which isn't hard. Most of the games feral has ported recently aren't games I'm really into anyway.

Please also note that, in addition to Eike's statement, there are always several layers that wrap lower layers underneath until your call reaches the hardware. In the end the result is always a native Linux process, otherwise it wouldn't start.

I get you point, but in the end it just matters if the process is stable and performs. Give it some time, I guess we will see more projects with Linux in mind from the beginning on once publishers and studios got the idea that money can be earned on Linux. Currently it is simply financially not feasible to invest the time to get all out of Linux, the small performance penalty is the price for our small market share. A price I'm happy to pay for to have at least some very cool big titles on Linux and to have a chance to attract more people for gradually grow which will hopefully increase our market share. That in turn should make heavier investments into Linux feasible. I guess you get my idea :)


Last edited by jens on 28 January 2018 at 7:10 pm UTC

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