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

DCS World, please!

I just read earlier today that they are looking at Vulkan. First I thought, why, it's performing perfectly well after they implemented their new engine running on d3d11. Hmmm.... LINUX!? Then I realized it's probably to improve the VR experience, but one could only hope they are looking at us as well.

Haven't played with it in a few years though. I really liked it but at some point I got too fed up by the draconic DRM, increasingly large amount of smaller DLC's splitting the game to pieces, the never ending simultaneous dual branches (1.5|2.0), the promises of awesome modules which never came until years or even decades after their initial expectations. Ended up selling my flight sim hardware and a lot of DCS modules. Back then you could sell them second hand but they don't allow that now so I'm glad I jumped ship when I did actually.

I wish we could get Elite: Dangerous ported. It's about the only game I reboot into Windows for. I mean lately I decided to win the latest Doom, but other than that it's been all Elite.

Would like Bioshock + Bioshock 2. Remastered or not.
Also +1 for any LEGO games.

Is adding a wine-like wrapper considered a port these days? still feels wrong to me

Is adding a wine-like wrapper considered a port these days? still feels wrong to me

I don't like it either. Although 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.

Is adding a wine-like wrapper considered a port these days? still feels wrong to me

It's all just code being executed that is proprietary in nature, so if it runs perfectly well, does it matter?
It's not like any of these games are developed with GNU/Linux in mind. They're ported, after being made for Windows. If binaryA runs just as well as binaryB though, with all other things being effectively equal, it's still just a binary black "box" blob for reading user input and painting pixels on the screen.

I personally don't like the idea of Windows wrappers and compatibility layers. I've been hesitant to but feral games in the past because of this and I try to buy and play more indie games but when feral releases a game I've been really wanting to play I'll buy it and play it.

Although 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?


Last edited by Eike on 28 January 2018 at 12:53 pm UTC

Although 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?

Yeah 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.

Is adding a wine-like wrapper considered a port these days? still feels wrong to me

It's all just code being executed that is proprietary in nature, so if it runs perfectly well, does it matter?
It's not like any of these games are developed with GNU/Linux in mind. They're ported, after being made for Windows. If binaryA runs just as well as binaryB though, with all other things being effectively equal, it's still just a binary black "box" blob for reading user input and painting pixels on the screen.

I personally don't like the idea of Windows wrappers and compatibility layers. I've been hesitant to but feral games in the past because of this and I try to buy and play more indie games but when feral releases a game I've been really wanting to play I'll buy it and play it.

It is, unfortunately, a necessary evil if we want games that are primarily aimed at Windows. Replacing the entire engine and reworking it to fit with a graphics API it was never originally intended to target can be time consuming, error prone, and not really a viable business model.

Indie games of course are more flexible in this regard for a great variety of reasons (there's really too many to mention here), but sometimes it's nice to have something a little grander in scope (not that indie games can't be, but I hope you get the point).

Still hoping for game engines to gradually support GNU/Linux not only as a build target, but as a development platform as well. That will likely only happen once there's enough snowballing to challenge Windows as a gaming platform, and that's not going to happen overnight. Until then, basically have to put up with things as they are.

Besides which, most game engines have their own abstraction layer internally anyway to cover differences between, say, x86_64, playstation, xbox, etc. How much of that gets replaced by a porter depends how easily they can plug into it.

Yeah I get your point about the indie games and I know we don't really get to be picky about our ports right now. If only we had that luxury although there is a certain amount of crap I personally won't put up with. When VP shipped native windows dlls with their saints row port I just refunded it and won't buy their games anymore. The engine situation is getting better and better but the biggest problem I see is a lot of AAA studios either roll their own engine or heavily customize an existing one and generally when they do the customization they only mess with the Windows/D3D backend since that's the only platform they're targeting. That's a problem I'm not sure how to solve. That's what's holding up killing floor 2. They changed the D3D backend for unreal engine and now they have to find someone to port it.

Although 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.

Yeah 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

Although 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

Binary 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.

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.

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.

Binary 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

Binary 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

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.

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.

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

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

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.

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