John Carmack asks why Wine isn't good enough.
http://www.reddit.com/r/linux/comments/17x0sh...gh/c89sfto
http://www.reddit.com/r/linux/comments/17x0sh...gh/c89sfto
I wish Linux well, but the reality is that it barely makes it into my top ten priorities (Burn the heretic!); I use Linux for the flight computers at Armadillo Aerospace, but not for any regular desktop work. I was happy to hear that Rage ran in Wine, but no special effort was made to support it.
I do get tempted to port to Linux for technical reasons – I would like to use Valgrind again, and Nvidia has told me that some experimental GPU features I would like to use for R&D would be easier to prove out on Linux. Working on open source Linux OpenGL drivers again would also be fun if I ever had the time.
However, I don’t think that a good business case can be made for officially supporting Linux for mainstream games today, and Zenimax doesn’t have any policy of “unofficial binaries” like Id used to have. I have argued for their value (mostly in the context of experimental Windows features, but Linux would also benefit), but my forceful internal pushes have been for the continuation of Id Software’s open source code releases, which I feel have broader benefits than unsupported Linux binaries.
I can’t speak for the executives at Zenimax, but they don’t even publish Mac titles (they partner with Aspyr), so I would be stunned if they showed an interest in officially publishing and supporting a Linux title. A port could be up and running in a week or two, but there is so much work to do beyond that for official support. The conventional wisdom is that native Linux games are not a good market. Id Software tested the conventional wisdom twice, with Quake Arena and Quake Live. The conventional wisdom proved correct. Arguments can be made that neither one was an optimal test case, but they were honest tries.
If you fervently believe that there is an actual business case to be made for Linux ports, you can make a business offer to a publisher – offer a guarantee and be willing to do the work and support. This is what Aspyr does for the Mac, and what Loki did for Linux. However, you probably can’t even get an email returned if you are offering less than six figures to a top ten publisher. This may sound ridiculous – “Who would turn away $20,000?” but the reality is that many of the same legal, financial, executive, and support resources need to be brought to bear on every single deal, regardless of size, and taking time away from something that is in the tens of millions of dollars range is often not justifiable.
I truly do feel that emulation of some sort is a proper technical direction for gaming on Linux. It is obviously pragmatic in the range of possible support, but it shouldn’t have the technical stigma that it does. There really isn’t much of anything special that a native port does – we still make OpenGL calls, winsock is just BSD sockets, windows threads become pthreads, and the translation of input and audio interfaces don’t make much difference (XInput and Xaudio2 are good APIs!). A good shim layer should have far less impact on performance than the variability in driver quality.
Translating from D3D to OpenGL would involve more inefficiencies, but figuring out exactly what the difficulties are and making some form of “D3D interop” extension for OpenGL to smooth it out is a lot easier than making dozens of completely refactored, high performance native ports.
Ideally, following a set of best practice guidelines could allow developers to get Linux versions with little more effort than supporting, say, Windows XP.
Properly evangelized, with Steam as a monetized distribution platform, this is a plausible path forward.
John Carmack
I do get tempted to port to Linux for technical reasons – I would like to use Valgrind again, and Nvidia has told me that some experimental GPU features I would like to use for R&D would be easier to prove out on Linux. Working on open source Linux OpenGL drivers again would also be fun if I ever had the time.
However, I don’t think that a good business case can be made for officially supporting Linux for mainstream games today, and Zenimax doesn’t have any policy of “unofficial binaries” like Id used to have. I have argued for their value (mostly in the context of experimental Windows features, but Linux would also benefit), but my forceful internal pushes have been for the continuation of Id Software’s open source code releases, which I feel have broader benefits than unsupported Linux binaries.
I can’t speak for the executives at Zenimax, but they don’t even publish Mac titles (they partner with Aspyr), so I would be stunned if they showed an interest in officially publishing and supporting a Linux title. A port could be up and running in a week or two, but there is so much work to do beyond that for official support. The conventional wisdom is that native Linux games are not a good market. Id Software tested the conventional wisdom twice, with Quake Arena and Quake Live. The conventional wisdom proved correct. Arguments can be made that neither one was an optimal test case, but they were honest tries.
If you fervently believe that there is an actual business case to be made for Linux ports, you can make a business offer to a publisher – offer a guarantee and be willing to do the work and support. This is what Aspyr does for the Mac, and what Loki did for Linux. However, you probably can’t even get an email returned if you are offering less than six figures to a top ten publisher. This may sound ridiculous – “Who would turn away $20,000?” but the reality is that many of the same legal, financial, executive, and support resources need to be brought to bear on every single deal, regardless of size, and taking time away from something that is in the tens of millions of dollars range is often not justifiable.
I truly do feel that emulation of some sort is a proper technical direction for gaming on Linux. It is obviously pragmatic in the range of possible support, but it shouldn’t have the technical stigma that it does. There really isn’t much of anything special that a native port does – we still make OpenGL calls, winsock is just BSD sockets, windows threads become pthreads, and the translation of input and audio interfaces don’t make much difference (XInput and Xaudio2 are good APIs!). A good shim layer should have far less impact on performance than the variability in driver quality.
Translating from D3D to OpenGL would involve more inefficiencies, but figuring out exactly what the difficulties are and making some form of “D3D interop” extension for OpenGL to smooth it out is a lot easier than making dozens of completely refactored, high performance native ports.
Ideally, following a set of best practice guidelines could allow developers to get Linux versions with little more effort than supporting, say, Windows XP.
Properly evangelized, with Steam as a monetized distribution platform, this is a plausible path forward.
John Carmack
Edited by unihumi at 14:22 CST, 6 February 2013 - 4310 Hits