Announcement

Collapse
No announcement yet.

John Carmack Shares More Of His Linux Views

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

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

    Comment


    • #3
      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; 06 February 2013, 12:53 PM.

      Comment


      • #4
        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.

        Comment


        • #5
          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; 06 February 2013, 01:18 PM.

          Comment


          • #6
            - 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)

            Comment


            • #7
              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.

              Comment


              • #8
                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?

                Comment


                • #9
                  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...

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X