I disagree and I openly dislike this tone many Linux users have taken (no offense though). Things have changed radically and there's really no point to stick with Windows, considering last sane version slowly slipping away and no way I am gonna touch Windows 10.
ED is last thing why I have Windows installation.
I think whether they'll bother with the Linux port depends on the uptake of SteamOS and Android gaming platforms. Android on a suitably powerful machine with the right OpenGL libraries installed is a lot closer than the year of the Linux desktop, imo.
I was browsing a Linux magazine which featured a monitor with Elite Dangerous displayed on the screen! Do they know something we don't..
Nope, not really. Android is so cut-back, that it hasn't to do much with Linux or a Desktop OS. Most tools and control methods are lacking, you cannot work with it like you work with a regular OS. Plus, it is slow and unstable. It can't even compete on mobiles in technical terms with more superior plattforms like QNX.
For the end user, Linux on the Desktop is like OSX, with better hardware support and a (often worse) choice of window managers. But most of the basics are the same, except for the ways to control daemons. Android is far from reaching that level of maturity, and Windows behaves completely different.
Not quite true, and I'm not going to jump into the micro-kernel (QNX) mono-kernel(Linux) debate, because its not relevant here.
A game like ED generally runs on top of the kernel interfaces, not the Android "window manager/OS" that runs on top of the Linux kernel, (unless the game was written in Java like minecraft).
It either interfaces directly with the kernel, or through a direct to kernel abstraction layer like SDL or OpenGL. In principle, whether its Android or KDE, it does not matter. The window manager generally gets out of the way, or is pushed into the background as the native application takes over the screen. I think the biggest difficulty with an Android port (common abstractions like OpenGL and SDL being available already), is dealing with the overhead of building and testing ED in a predominantly non x86 processor architecture ecosystem.
In principle, whether its Android or KDE, it does not matter. The window manager generally gets out of the way, or is pushed into the background as the native application takes over the screen. I think the biggest difficulty with an Android port (common abstractions like OpenGL and SDL being available already), is dealing with the overhead of building and testing ED in a predominantly non x86 processor architecture ecosystem.
It's an educational problem rather than a marketing or awareness problem.
For those want to understand what's Steam Machines are about (physically)
http://www.pcworld.com/article/2893...ails-and-pictures-for-every-model.html#slide1
I have to say some of those are very sexy beasts.
I was browsing a Linux magazine which featured a monitor with Elite Dangerous displayed on the screen! Do they know something we don't..
It appears that this thread has gotten derailed somewhat. Hypothetical and philosophical arguments aside, I would be more than happy in creating a new thread (mods agreement OFC) on how we can actually push forward in getting it working (thx to an earlier suggestion).
Personally I am more than willing to start off a more technical thread on the possibility that we may indeed get it to run through some sort of WINE/POL method.
P.S. this whole thread has made for some fantastic readingHowever with the supposedly imminent arrival of the new DX11 wrapper for wine, maybe a new thread could concentrate more on that?
fixme:dxgi:dxgi_output_GetDisplayModeList iface 0x1bf968, format DXGI_FORMAT_B8G8R8A8_UNORM, flags 0x1, mode_count 0x2a0e844, desc (nil) partial stub!
fixme:dxgi:dxgi_output_GetDisplayModeList iface 0x1bf968, format DXGI_FORMAT_B8G8R8A8_UNORM, flags 0x1, mode_count 0x2a0e844, desc 0x10bd7d40 partial stub!
fixme:d3d113D11CoreCreateDevice Ignoring feature levels.
fixme:dxgi:dxgi_device_init Ignoring adapter type.
fixme:d3d11:device_parent_create_swapchain_surface device_parent 0x1b8c30, container_parent 0x1f3af0, wined3d_desc 0x2a0e1f4, surface 0x2a0e1dc partial stub!
fixme:d3d11:device_parent_create_swapchain_surface Implement DXGI<->wined3d usage conversion
Can we you post this as the start for that new thread?Today for no good reason I decided to hack around a bit and play around ED on Wine. Previously I never got further about installation. This time I got one step ahead - as previously reported on this thread, I got run a launcher. For technical details story is this - there's no big issues running actual .NET 4.0 libraries on Wine, at least for wine 32-bit prefix. Problem however is installation - Microsoft tends to make these complex installation paths with various tools. Part of .NET 4.0 dlls are installed using Windows service WUSA, which is not implemented yet in Wine. One of these dlls - mscoree.dll - is main reason why EDLauncher most likely won't run on clean Wine install, as it is simply missing, nevermind that .NET installer told you everything's peachy (in short it's lying). What I did I installed it on Windows 32-bit version and dug out and put in right place (windows/system32). And vola, it worked. View attachment 61346 Visuals appear at first and then disappear as you move around it but big button is still there and that's all what matters. However login works, machine verification works, download and installation works. Fun was cut short however as despite me running second to newest development Wine I got nice 'fixme' lines as expected: So it is just beginning of the road. As Wine development version 1.7 (currently at 1.7.51) gets more and more code for DirectX11 support I will report on how ED runs on it time after time.