Page 1 of 3 123 LastLast
Results 1 to 10 of 22

Thread: John Carmack Shares More Of His Linux Views

  1. #1
    Join Date
    Jan 2007
    Posts
    14,371

    Default John Carmack Shares More Of His Linux Views

    Phoronix: John Carmack Shares More Of His Linux Views

    John Carmack, the co-founder of id Software that's widely known through gaming circles due to his remarkable work on developing Doom and Quake and other titles, sparked some controversy earlier this week when he promoted Wine for Linux gaming over native Linux game ports. He's now provided some additional clarification and thoughts...

    http://www.phoronix.com/vr.php?view=MTI5NTA

  2. #2
    Join Date
    Oct 2012
    Posts
    149

    Default

    What's all the hassle? M$ market share is already down to ~70% in Switzerland and continues to fall...

  3. #3
    Join Date
    Jan 2012
    Posts
    179

    Default

    Quote Originally Posted by BO$$ View Post
    Microsoft is so last decade. They are dead. Most devs should focus on building on linux first and then maybe porting to windows. Hell even Microsoft thinks of porting office to linux...
    Not because Linux would yet be the more lucrative market, but simply because designing for linux equals to following best coding practice guidelines.

    Also, porting is unnecessary. Cross platform compatibility comes almost for free if you design the program wisely from the get-go. This is why i tend to agree with carmack on this issue. Use WINE for current titles, design next-gen titles to be crossplatform - forget porting old shit that was designed in a darker age.
    Last edited by varikonniemi; 02-06-2013 at 11:53 AM.

  4. #4
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote Originally Posted by varikonniemi View Post
    Not because Linux would yet be the more lucrative market, but simply because designing for linux equals to following best coding practice guidelines.
    If and whwn Linux gets high uality modern APIs and tools,maybe. it's currently way easier and less frustrating to get a modern renderer up snd running using Microsoft's APIs and tools. As a developer with a budget and timeline, that matters. The only thing Linux has which Windows is missing is Valgrind. Meanwhile, Linux is completely lacking in high quality GPU debugging tool, and OpenGL/OpenAL are simple awful APIs. OpenGL has an excuse in that it is ancient; OpenAL has none, it was just designed by morons who copied OpenGL. Which is why so few real games use OpenAl directly and pay for fmod or wwyse, and why game devs prefer D3D9/11 over GL. Better APIs save time and money, as do better tools.

    With OpenGL, if your renderer doesn't work, good luck figuring out why. Way easier to get everything working on D3D/Windows and port after you know your game is corect and works.

  5. #5
    Join Date
    Jan 2012
    Posts
    179

    Default

    Valve already demonstrated how hopelessly poor windows/d3d is as a 1st class gaming platform when source runs much faster on Linux/ogl than it does after years of optimizing for win/d3d. You cannot have the cake and eat it too. Choose either simplicity or quality.
    Last edited by varikonniemi; 02-06-2013 at 12:18 PM.

  6. #6
    Join Date
    May 2010
    Posts
    684

    Default

    - Specifically about Direct3D translating: "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."
    I'm fairly sure valve is already using some sort of d3d > opengl translation layer for their ports (I recall reading that somewhere)

  7. #7
    Join Date
    Dec 2009
    Location
    Tallahassee. FL
    Posts
    126

    Default

    This is clearly Carmack responding to the great strides made over at Valve in the Linux user space. Wine is great for running Old games that have no chance of a port. It is a really neat piece of software but its not a optimal solution. Even Blizzard is thinking of releasing a Linux native title. I have played three WoW expansions, StarCraft 2, and Diablo III. All play alright but you can really tell the difference if you play them native. Believe me, I got them working but it was hard to do at times.

  8. #8

    Default

    I think most of the AAA players will be the LAST ones to adopt Linux, while the indie guys, and Valve, who still has the indie spirit, will be the first to adopt it. With OpenGL ES 3.0 games coming to both hundreds of millions of iOS and Android devices, it should be easy to port the same games to Linux, too, especially with more engines like Unity supporting it. I hope Unreal 4 supports it, too. Last I checked they were undecided. But I hope they will.

    It's still disappointing Carmack is not on the "indie" side anymore, but what can you do?

  9. #9
    Join Date
    Dec 2008
    Posts
    82

    Default Nonsense...

    A good shim layer should have far less impact on performance than the variability in driver quality.
    This sentence doesn't make any sense. Doing a shim layer won't make disappear the "variability" in driver quality.
    You just throw back the problem to the Wine developers...

  10. #10
    Join Date
    Aug 2012
    Posts
    245

    Default

    Quote Originally Posted by spykes View Post
    This sentence doesn't make any sense. Doing a shim layer won't make disappear the "variability" in driver quality.
    You just throw back the problem to the Wine developers...
    I think he means the shim is a less important factor on the loss of performance than some drivers that don't have high performance, but both will affect it(in other words there are issues regarding performance with higher priority than the ones coming from the shim).
    Besides, at least from my understanding, what wine does is that when the wine dll is called, it calls a linux native function instead of a windows native function, at worst you get an extra function call in between. Whether the linux native functions or code within the wine dlls are optimized is of course another matter, not connected with inherent issues of the implementation.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •