Sign In
Create Account
Login to Account Create an Account
Active Topics
- Insomniac's late night hangout
Today, 05:33 PM by qubit - [News] [PR] NVIDIA Releases GTX 780 Graphics Card
Today, 04:41 PM by qubit - [News] [PR] High-End PC Case Maker Lian Li to Unveil New Products at COMPUTEX 2013
Today, 12:22 AM by qubit - DRM peddler shuts down, stiffs customers
Yesterday, 11:30 PM by FreedomEclipse - COLD FUSION is BACK with 'anomalous heat' claim
Yesterday, 10:57 PM by qubit - [News] [PR] Genius to Showcase New Line of Hybrid Peripherals and Award Winning GX Gaming Series at COMPUTEX Taipei 2013
Yesterday, 10:25 PM by qubit - The Official 'What are you listening to' Thread!
Yesterday, 09:56 PM by FreedomEclipse - Did they really fire this female reporter for a small slip of the tongue?!
Yesterday, 09:27 PM by qubit - Speed cameras are a scam, Ohio judge rules
Yesterday, 02:43 PM by Pegasus - Desktop Shutdown and Standby/Hibernate Icons
Yesterday, 11:54 AM by qubit
Advertisement
Newest Downloads
- Intel Rapid Storage Technology 12.6.0.1033
Today, 01:36 AM in Drivers - GPU-Z 0.7.1
May 17 2013 05:41 PM in Utilities - Intel PRO/Ethernet 18.2
May 13 2013 01:02 AM in Drivers - Intel USB 3.0 for 8x chipsets v2.0.0.102
May 13 2013 01:01 AM in Drivers - AMD RAID 13.4
Apr 25 2013 02:41 AM in Drivers - AMD chipset 13.4
Apr 25 2013 02:40 AM in Drivers - AMD Catalyst 13.4
Apr 25 2013 02:26 AM in Drivers - Realtek PCI Express Ethernet 7.069
Apr 08 2013 02:35 PM in Drivers - Realtek High Definition Audio Codec 2.71
Apr 08 2013 02:27 PM in Drivers - Asmedia USB 3.0 v1.16.4.0
Apr 04 2013 02:15 AM in Drivers
Today's Wallpaper
Recent Blog Entries
- Welcome to my new Blog!
Mar 15 2012 11:22 PM by alexp999 - My Issues with Sony's PSVita and Nintendo's 3DS. (Warning: Very long winded)
Sep 07 2011 06:41 PM by CDdude55 - From: Useful Software Thread
Jun 24 2011 06:23 PM by alexp999 - Welcome to the new look techngaming.com!
May 22 2011 05:44 PM by alexp999
1
Editorial Id's John Carmack Writes Off Linux as a Gaming Platform
Click image to enlarge
Advertisement
He feels that the emulation route via WINE is the best option, since major software companies won't invest in making native Linux games. He does make a nod to Valve's efforts to get Steam onto Linux however.
I'm surprised that he's so negative about native Linux games, since Valve's Steam efforts are quite serious and could crack open this market. They are developing their Steam Box after all, which will run Linux. They have already ported development versions of the Steam client and Left for Dead game for testing, which are working very well. Crucially, they are getting the same frame rate performance in Linux as in Windows, too. Because of these developments, I think Carmack should put the past aside and perhaps work with Valve?
Think, how many regular people, rather than businesses, really need to use Windows? Not as many as you think, since Linux provides great apps for many regular tasks that people do, which is often just internet browsing and email. Since Firefox already works on Linux, a major nut is cracked right there, especially as many people use webmail anyway and for word processing and other "office" tasks, there's always the likes of the free Open Office and similar software suites to take care of them.
Carmack posted his view on Reddit, which I have reproduced in full, below.
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
4 Comments
He is, in a way, right. Linux has poor market penetration, no matter how you look at it and I bet the percentage of linux users that don't play games is close to half of the total userbase. This pushes every publisher away from the platform. OpenGL has been around for a really long time and it as capable as DX, so the fault isn't there. It would take a game, exclusive to linux, that everybody would want to rock the markets. I can see this happening if Valve, for example, restricted HL3/HL2:ep.3 to the linux version of steam for a whole month after its release. Or something like "TF2-Linux Month". Although that would piss-off users, instead of nudging them to change platforms.
Yeah, one does tend to err on Carmack's side, but Valve are massive in the gaming space, which is why I don't think Linux should be written off, but no one can say either way with any certainty.
It's a classic case of wait and see.
I have to agree with John. I know Steam Box is going to have direct frame buffering implemented. But I seriously doubt the old school *nix developers will ever break the old philosophy and widely support a single-user application with direct frame buffer support ... which is what is needed to crank out as much power as you can from the video card hardware.
Linux users are a lot less...cranky when it comes to the graphics they are getting on their desktop. But the framerates on linux tend to be lower and a lot of the video effects are cut on Linux ports. Even if with enough hacks implemented they are running relatively the same as Windows that is still pathetic for Linux. A Linux box has a fraction of the overhead and just straight crap loaded of junk running in the background as a Windows system. A Linux box with a kernel level direct frame buffering and a application that can access that direct frame buffer should be running laps around Windows. Unfortunately getting core devs to accept things like DirectFB has been impossible and met with great resistance as it breaks traditions and old design philosophies. Well... compatibility too. So basically we are stuck where we were back in Windows 3.x days when Microsoft was insisting everything could be done through GDI and eventually they relented and went with the redesign of Direct X as a sub-OS for games. In the early days of Direct X there was actually two drivers for video cards. The GDI driver and the Direct X driver if your card had it. Eventually Microsoft got rid of GDI drivers (DX3?) and went with Direct X as the driver and the GDI interfaced DX.
Linux core developers have been stubborn about this one. In fact, more stubborn than audio about video rendering. When I say core.. I don't mean kernel developers I mean distro developers. Kernel wise everything is there. Kind of why this is a troll topic as John hinted at.
But no matter how many commercial products based on Linux or BSD that implements a kernel direct frame buffering sub-system is shown to these folks they just refuse to give up on the GDI-like philosophy. Hard to be too optimistic.
So there's just as much politics, bureaucracy and stubborness in the Linux world as anywhere else and that's holding it back? Well, perhaps that's the whole reason why Linux never gets anywhere on the desktop?
Yes, DX/Windows has an awful lot of overhead crap in it that reduces framerate significantly. It was especially noticeable when moving from XP to Vista and it's never gotten any better (I ran some actual benchmarks and the difference was around 30% worse in the worst cases). My pet theory is that it's the crummy DRM Protected Media Path causing this overhead, but I've never seen a definitive explanation for this slowness though.
I'd say it's criminal then, that Linux doesn't run rings round it. Just think, what's the primary performance metric that sets the price of a graphics card - framerate performance, end of story. Therefore, fixing this would give Linux a massive advantage over Windows. This opportunity shouldn't be wasted like it is.
Could you please explain what this direct frame buffering is? It sounds like direct hardware access to the graphics card memory.
Good insight there BadOPCode and welcome to tng.