Elite:Dangerous for Linux?

[Noobilite]

No, But they can more easily read disproportionally larger text! >< That was a header so people got the point and didn't lose it in the wall of text. It's for formatting purposes!

I'm surprised people are not excited about this. I would imagine if we can get this far the rest might be fixable if we found people with more knowledge on the subject.

 

[Cmdr Eagleboy]

No, But they can more easily read disproportionally larger text! >< That was a header so people got the point and didn't lose it in the wall of text. It's for formatting purposes!

I'm surprised people are not excited about this. I would imagine if we can get this far the rest might be fixable if we found people with more knowledge on the subject.

Nice moves commander! So far I failed to get ED running fully with 2.20 I think, but I haven't tried 3.0 rc. I will try again and report findings.

There is hope that we could get ED running under Wine reliably, now even more than ever.

 

[Noobilite]

If you use PlayOnLinux use 2.21-staging, install dotnet4.0; xinput; and open wine settings(configure wine) and change it to windows xp at the bottom(not sure what the normal wine equivalents are.). It's in the applications tab and at the bottom. It's a pull down list: Windows Version: [box with list].

You may need the staging version. I haven't tried the non staging. But I will in a second.

If you get the demo up it might not always load. It takes a few tries sometimes and has to sit for a few minutes or more potentially.

I forgot a potentially important detail. It's in a 32 bit bottle. 64 bit won't work the same way from my tinkering.

Testing it with 2.20 normal and it gets the launcher up and seems to be acting the same. Haven't gotten the game window up full yet though. I'm willing to bet if it's not working at all and the launcher doesn't start it may be from a 64 bit bottle. I totally forgot it doesn't work in 64 bit windows for me yet. Unless wine and pol are acting differently.

Edit: I tested it with 2.20 non staging. It worked, but it had no graphics. You could read the text for options etc once the demo loaded but the other stuff was all black. 2.21 staging gets rid of this. Everything else seemed to act the same. Including the crashing. the crashing seems to be the interface in the main window before you start. If you get into the cockpit this seems to all but disapear. If you are in a context window before starting it very easily freezes the interface. I'll have to test more versions.

Also, non staging so far seems to leave a greater chance of it leaving a process up. If it does this find the elite process and kill it. It will stop further versions from starting and cause other odd issues.

Sadly 3.0 isn't on Pol yet.

Versions:
(32bit)
2.22: seems to work the same as 2.21-Staging.(haven't gotten fully into tutorial though)
2.21-Staging: best working version so far.(haven't tested many others.)
2.20: Black missing screen context.
(64bit)
2.22: Opens 64bit client directly but black screen. Hasn't loaded successfully yet. But might.
2.21-Staging: testing

Edit: I have been using the .exe in: .PlayOnLinux/wineprefix/Elite_Dangerousx32/drive_c/Program Files/Elite Dangerous/EDLaunch.exe

I just found there is the 64 bit exe in: .PlayOnLinux/wineprefix/Elite_Dangerousx64/drive_c/Program Files (x86)/Elite Dangerous.ori/Products/elite-dangerous-64/EliteDangerous64.exe
There is also: .PlayOnLinux/wineprefix/Elite_Dangerousx32/drive_c/Program Files/Elite Dangerous/Products/COMBAT_TUTORIAL_DEMO/EliteDangerous32.exe

I'll try the other two. Using the 64 bit one in a 64 bit bottle has been getting it to open the client window so far. And using the 32bit exe in 32bit went quicker and easier to the tutorial stuff.

I'm mistaken. The 32 bit bottle won't open the EliteDangerous32.exe directly. But if you open the folder and double click it it will open the client window for the tutorial.

BINGO! I did the same thing with the 64bit client and it opened fullscreen(although it did not display the whole screen and I had to move around.). It then showed the horizons logo, then went to the hardware auto prep screen and started to try to "prepare the shaders.." Alt tabbing in and out of the client window succesfully make it proper full screen. I don't know what happened but it may have loaded with the system stock wine or simply wine... I have no idea what it is using. But it's trying to work! Is this where everyone else got stuck?

If this is working in normal wine it's 2.19-staging. I have no idea what else. To work it has to be allowed to load for a long time on the black screen. Eventually it starts to do what it does in POL. sometimes it doesn't work though and you have to restart. The libraries in normal wine have dx9 and a bunch of other stuff installed. How do you get a lits of it without typing it all out?

Each time I start it it restarts where it left off preparing the shaders. I may get in the game.. 8)

The last thing I used normal wine for was FFXI.. So, I'm not sure of all I did to it:

Change: .wine/drive_c/users/****/Local Settings/Application Data/Frontier Developments/Elite Dangerous/Options/Graphics/DisplaySettings.xml
<FullScreen>1</FullScreen>
to:
<FullScreen>false</FullScreen>
0 doesn't work.

Enable CSMT for better graphics(checked)
Wine2.19-Staging
Windows 7
d3dx9_24-43 (native)
devenum (native)
iexplore.exe (native)
itircl (native,builtin)
itss (native,builtin)
jscript (native,builtin)
msctf (native,builtin)
mshtml (native,builtin)
quartz (native)
shdoclc (native,builtin)
shdocvw (native,builtin)
shlwapi (native,builtin)
updspapi (builtin)
urlmon (native,builtin)
winhttp (native,builtin)
wininet (native,builtin)
xmllite (native,builtin)

This is from a previous game. I have no idea what is or isn't needed. But you can start the 64bit exe directly and it tries to start. I'm pretty sure it's 64 bit.

Update: 98% through, "Preparing planetary generation system." I'm letting it sit to see how far it gets. I apparently got past shaders. So hopefully this works.

BTW, when the client has started loading successfully you will hear the game music start. Leave it sit black until you hear it. If it feels like it takes too long then restart it.

Got impatient and restart it at 98%. It restarted the shader loading. Hopefully it continues. It may help to leave it in the background after the music starts and not look at it. It seems like it may be causing problems. It acts a little different each time I restart. Hopefully I get lucky at some point.

Does anyone know anything else that might get this working better? I also couldn't find some of those in POL. Is there a way to load all of those to try with it? Some aren't there and some won't install in 64 bit bottles in POL.

 

[lenna]

Nice moves commander! So far I failed to get ED running fully with 2.20 I think, but I haven't tried 3.0 rc. I will try again and report findings.

There is hope that we could get ED running under Wine reliably, now even more than ever.

Since FD no longer support 32-bit binaries you will have to find another option.

 

[Noobilite]

The demo still uses 32bit by the looks of it. You can play the demo atm. You just have to get in without it crashing. And for me it has red and black to grey colors. But you can fly around and do the missions.

 

[Newt Loranas]

I actually fired off an email about this to Frontier. The reply came back that the issue with Elite Dangerous for Linux and indeed Mac is that OpenGL can't display the planetary textures. While Wine may be able to catch the methods and objects being referenced it may always be limited by what can be translated to OpenGL. We are going to rely on OpenGL in the future being able to produce the same effects as DirectX so that the textures can be displayed properly. It may be possible to get Elite Dangerous running in Linux therefore.. but not Horizons at present.

I'm in no way suggesting "give up". Just the wait may be a long time.

 

[Noobilite]

Do those planetary textures exist in the demo? I could play the game there but it was all funny colors. It was basically playable if you don't mind feeling like a massive ohio state fan.

That is partly why I mentioned the idea about a low retro graphics mode. Could get a basic mode to start in with retro 1984 graphics and play elite like it were the original game with no graphics issues. Might be a fun thing to have added to the game. That or just a shaderless mode. I've played many a game walking on invisible floors.

The more annoying issue seems to be it not liking whatever the pre ingame windows are made up. That is what crashes it the most.

Pic Incoming:

https://imgur.com/hUxjRRG

 

[Newt Loranas]

Do those planetary textures exist in the demo? I could play the game there but it was all funny colors. It was basically playable if you don't mind feeling like a massive ohio state fan. I would take pics but I don't have a free image host after my last one went non free. I'll find a new one and try to post a pic.

That is partly why I mentioned the idea about a low retro graphics mode. Could get a basic mode to start in with retro 1984 graphics and play elite like it were the original game with no graphics issues. Might be a fun thing to have added to the game. That or just a shaderless mode. I've played many a game walking on invisible floors.

The more annoying issue seems to be it not liking whatever the pre ingame windows are made up. That is what crashes it the most.

The short answer is : I don't know

My educated guess is : No they are not in the demo. Nor are they in the base game which is why you can get ED for Mac but not Horizons. By planetary Textures I'm guessing they mean the detailed surface textures applied to the landscape when you're in sub-orbital flight, glide and surface

I could deal with just playing the space side though. Better than nothing.

 

[lenna]

I actually fired off an email about this to Frontier. The reply came back that the issue with Elite Dangerous for Linux and indeed Mac is that OpenGL can't display the planetary textures.

That is not exactly true, anything that can be done in DirectX can be done using OpenGL in essence. The problem is that there are differences in the way things work that means it is not necessarily a simple direct port and would most likely require a complete rewrite of the rendering engine. The thing is, once the rewrite is done it should work on any platform (at least in theory) but it would be ALOT of work in all likelihood and could be subject to hardware compatibility issues due to vendor specific extensions to OpenGL maybe doing the same things in different ways.

IMO FD's best option for ED on Linux would be to go down the Steam compliance route. How practical that would be from a commercial, technical, and project management perspective is another matter.

 

[Cmdr Eagleboy]

Since FD no longer support 32-bit binaries you will have to find another option.

I already succeeded in running ED under Wine64, it actually works. All my testing recently is done under Wine64.

 

[Cmdr Eagleboy]

I actually fired off an email about this to Frontier. The reply came back that the issue with Elite Dangerous for Linux and indeed Mac is that OpenGL can't display the planetary textures. While Wine may be able to catch the methods and objects being referenced it may always be limited by what can be translated to OpenGL. We are going to rely on OpenGL in the future being able to produce the same effects as DirectX so that the textures can be displayed properly. It may be possible to get Elite Dangerous running in Linux therefore.. but not Horizons at present.

I'm in no way suggesting "give up". Just the wait may be a long time.

This is not exactly true. What's happened that MacOS/OS X uses OpenGL 4.1 - and Apple didn't want to upgrade it any further.

But compute shaders which are used in DirectX11.3 to generate planetary surfaces are in OpenGL 4.3.

What wine 3.0 will do is to convert DirectX11.3 compute shaders calls to OpenGL 4.3 compute shaders calls. And that's basically it.

Do those planetary textures exist in the demo? I could play the game there but it was all funny colors. It was basically playable if you don't mind feeling like a massive ohio state fan.

All texture issues - please report them to Wine Bugzilla. When do please report back bug numbers so we can subscribe to see progress.

 

[Cmdr Eagleboy]

That is not exactly true, anything that can be done in DirectX can be done using OpenGL in essence. The problem is that there are differences in the way things work that mean it is not necessarily a simple direct port and would most likely require a complete rewrite of the rendering engine. The thing is, once the rewrite is done it should work on any platform (at least in theory) but it would be ALOT of work in all likelihood and could be subject to hardware compatibility issues due to vendor specific extensions to OpenGL maybe doing the same things in different ways.

IMO FD's best option for ED on Linux would be to go down the Steam compliance route. How practical that would be from a commercial, technical, and project management perspective is another matter.

Compute shaders are pretty straight forward to be frank, it is simplest thing in both OpenGL/DirectX. Only issue is compile them to code that OpenGL can understand.

Biggest issue ED under wine is that it uses lot of fancy corner case mechanics to make universe work, especially textures. I follow few wine developers who hopefully will tackle this issue this year.

 

[Noobilite]

I got this far in the 64 bit version with normal wine and 2.19-staging.

It's mocking me! 8\

I guess I need the launcher for it. It got past all the initial loading stuff. Now I just need to get the launcher to work to try to get into the game potentially. Has anyone gotten that working in 64 bit? I think some of the wine entries did. I'll try some of that out. I'm a little worried I'm going to kill whatever has it working though. 8)

Having a hard time getting the stuff from the winehq installed. I don't really know how to use wine and the little I do keeps telling me it doesn't install in 64bit. Any help would be appreciated. Has anyone gotten the 64bit launcher to start?

 

[Cmdr Eagleboy]

I got this far in the 64 bit version with normal wine and 2.19-staging.

https://i.imgur.com/sZuBJH9.png

I guess I need the launcher for it. It got past all the initial loading stuff.

See my work on getting ED running under Wine https://forums.frontier.co.uk/showt...ng-Wine-EXPERIMENTAL-NOT-OFFICIALLY-SUPPORTED

In short 64-bit launcher works, launching game works, game gets CRC error I haven't understand yet. According to some wine devs it should get to main menu if CRC error is resolved.

As for textures - sometimes they do appear, sometimes they don't at all. But first CRC error has to be figured out.

 

[Morbad]

This stuff is infuriating. People sit and complain all day long but then say they switched over to windows to play something. If they would grow a pair of balls and stop doing it things might actually change. And because you decided playing the gme is more important than something you say you don't agree with everyone else has to suffer because one more windows machine has ticked up on their radar as playing the game. You not only increase the windows users but decrease the linux users statistically... Everyone who does this is their own problem. And sadly everyone elses. People need to develop some backbone and character and actually act on their conviction and stop being hypocrites. If you don't follow through nothing changes.

I was a Windows user before there was Linux, and I'd primarily be using Windows even without Elite: Dangerous. I just want more options.

Anyway, how is running the Windows version of the game with Wine any less of a cop-out?

The demo still uses 32bit by the looks of it.

The demo is based on Elite: Dangerous 1.3.x...

Do those planetary textures exist in the demo?

...which significantly pre-dates Horizons and it's planetary texture system.

 

[lenna]

Compute shaders are pretty straight forward to be frank, it is simplest thing in both OpenGL/DirectX. Only issue is compile them to code that OpenGL can understand.

I have no doubt that a DirectX to OpenGL compatibility layer is feasible to implement but my point was that if FD want to port it properly it would probably involve a major rewrite of code.

Biggest issue ED under wine is that it uses lot of fancy corner case mechanics to make universe work, especially textures. I follow few wine developers who hopefully will tackle this issue this year.

Transgaming did a fair job with WineX/Cedega so I am sure it can be done, the question may come whether they will encounter IP/Licensing related issues.

 

[Cmdr Eagleboy]

I have no doubt that a DirectX to OpenGL compatibility layer is feasible to implement but my point was that if FD want to port it properly it would probably involve a major rewrite of code.

Not rewrite, but extending OpenGL port yes. My suspicious is that it isn't what holds FD back though - controller support is. It is kinda there, but it is very patchy and there's no nice way to centralize that support.

There are some projects however who tries to solve this issue. RedHat seems to be also interested in multimedia and gaming on Linux for last year.

Transgaming did a fair job with WineX/Cedega so I am sure it can be done, the question may come whether they will encounter IP/Licensing related issues.

To be fair CodeWeavers have taken off in big way and they pay for all major Wine devs so buy a copy of Crossover if you want to support them. They also work on DirectX 11.3/DirectX 12 layers for Wine.

 

[lenna]

My suspicious is that it isn't what holds FD back though - controller support is. It is kinda there, but it is very patchy and there's no nice way to centralize that support.

Xinput controllers currently have support under Linux (I know that from something at work), native USB HID devices have been supported for a long time, and the VIVE is already supported under Linux. Not sure where Occulus sits on the Linux compatibility front but I believe they are not there yet and I am not sure of their plans for Linux support.

Proprietary USB driver based controllers are more problematic.

 

[Cmdr Eagleboy]

Xinput controllers currently have support under Linux (I know that from something at work), native USB HID devices have been supported for a long time, and the VIVE is already supported under Linux. Not sure where Occulus sits on the Linux compatibility front but I believe they are not there yet and I am not sure of their plans for Linux support.

Proprietary USB driver based controllers are more problematic.

First, things are moving to Wayland and second, xinput has been quite adaptive but is overall cumbersome to guarantee support for peripherals. There are one RedHat backed project to create libinput equal for devices not used for regular desktop usage, forgot the name.

Overall things are improving. Just need to do my share and keep popularize Linux.

 

[amigacooke]

What does the Linux support in subsequent FD products since ED suggest about FDevs view of Linux?