Announcement

Collapse
No announcement yet.

Valve's L4D2 Is Faster On Linux Than Windows

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

  • To me, the only thing that really matters is that Linux seems to be on par with Windows.
    I don't really care if it is 5% faster. The next engine benchmark might show Windows being faster by 7%.

    So what?

    Major problems got solved very quickly, progress was reportedly amazing.
    The effort, starting from an existing Mac OSX port, apparently hasn't any negative effect on the mood of the developers.

    Hey, THAT'S the real good news!

    Unless your codebase is entangled to troublesome 3rd party code (or generally crappy),
    you can do a proper Linux port without going through hell, obviously.
    I've to admit, all the FUD sounded quite legitimate sometimes. Not anymore!

    Comment


    • Even taking in account that it's all inside error margins , the fact remains that just because you play on Linux, you won't be penalized in performance because it's at worse, in same ball park...this is good taking in account that many said that Linux was plagued with bad video drivers (and to some extend this is ture because for starters the Nouveau driver is an under dog)...when after all, with the blobs anyway, they don't seem that bad after all and performance is not worse than in Windows.


      As for the fact that NVIDIA driver has it's own configurations per game in Windows and not in Linux (BUT that might change very soon now that there is a big push from Valve working with NVIDIA, well, 1st of all, i never really used them in windows anyway because i never see any dramatic change in performance....usually let all in stock and change not at an individual basis in the driver but in overall at driver and then in-game.

      Comment


      • Originally posted by entropy View Post
        Unless your codebase is entangled to troublesome 3rd party code (or generally crappy),
        you can do a proper Linux port without going through hell, obviously.
        Well I don't think that part is the newsworthy part. Developers knew that already.
        I think the newsworthy part is that one of the largest game/engine developers is actually committed to do so.

        In the old days, games were often supported on far more platforms than today, and also with far more differing specs.
        In the late 80s to mid 90s, we had C64, Atari ST, Amiga, PC, Mac, and various consoles. Many games were ported to 5 or more platforms.
        Look at Prince of Persia for example: http://en.wikipedia.org/wiki/Prince_of_Persia
        Apple II, MS-DOS, Amiga, Atari ST, Amstrad CPC, PC-9801, Commodore 64, PC Engine, Turbografx-16 CD, SAM Coup?, X68000, PS2, Xbox, Game Boy, NES, SNES, GBC, GCN1, Wii4, Mac OS, Master System, Mega-CD, Game Gear, FM-Towns, Mega Drive

        So games these days being released for Windows and one or two consoles? Not impressed.
        In the old days you were more free to choose what type of computer you bought, because a lot of games would be available for various computers anyway. You could just pick the computer that had the best ports of the games you liked. These days there is barely any choice in terms of hardware, it's all x86, and either nVidia or AMD GPUs, which aren't that different anyway. And the only OS you can run for most games is Windows.
        Last edited by Scali; 08-03-2012, 11:08 AM.

        Comment


        • well as long as you optimize and profile your code properly the performance will be set by the GPU[unless the CPU cant keep the GPU feeded] cuz remember valve tested a blob driver that pretty much uses the same render path in both OSes so unless you booboo and use pbuffers[for example] performance should stay in margin.[is irrevelant the API you use as long you choose a generation of the API accord with you hardware like i said before GPUs are lot dumber than CPUs]

          the real test if linux is faster or not will be once the native linux drivers are finished since those will trully use every advantage linux can offer, for now is good to know you can play the same in both OSes

          Comment


          • Originally posted by Scali View Post
            Well I don't think that part is the newsworthy part. Developers knew that already.
            I think the newsworthy part is that one of the largest game/engine developers is actually committed to do so.

            In the old days, games were often supported on far more platforms than today, and also with far more differing specs.
            In the late 80s to mid 90s, we had C64, Atari ST, Amiga, PC, Mac, and various consoles. Many games were ported to 5 or more platforms.
            Look at Prince of Persia for example: http://en.wikipedia.org/wiki/Prince_of_Persia
            Apple II, MS-DOS, Amiga, Atari ST, Amstrad CPC, PC-9801, Commodore 64, PC Engine, Turbografx-16 CD, SAM Coup?, X68000, PS2, Xbox, Game Boy, NES, SNES, GBC, GCN1, Wii4, Mac OS, Master System, Mega-CD, Game Gear, FM-Towns, Mega Drive

            So games these days being released for Windows and one or two consoles? Not impressed.
            Huh? In those days these "ports" to completely different architectures were typically rewrites.
            Which isn't such a big deal since they were relatively simple and tiny (albeit great games, sure).

            Comment


            • Originally posted by entropy View Post
              Huh? In those days these "ports" to completely different architectures were typically rewrites.
              Which isn't such a big deal since they were relatively simple and tiny (albeit great games, sure).
              So? Valve had to rewrite the Steam client as well, because originally they used the IE browser control. They had to rewrite it to use Webkit.
              Likewise they had to rewrite the Source engine's renderer from D3D to OpenGL, and the audio from DirectSound to <whatever they're using>. And who knows what else.
              So where does the 'huh?' come from? (yes, porting generally involves rewriting stuff).
              My point is merely that you can support a lot of platforms if you bother to put in the effort. It has only gotten simpler these days (same underlying hardware, only a different OS, you can even use the same APIs in a lot of cases).
              Last edited by Scali; 08-03-2012, 11:16 AM.

              Comment


              • I said "Huh?" because you were comparing ports of a rather complex heap of code of modern engines to
                countless "ports" of very old games which were mostly _complete_ "rewrites".
                Those were comparably trivial games (technically) to rewrite from scratch and that does not tell you anything about
                their "portability" (Maybe just that they were typically not portable at all).
                OTOH, the largest part of the modern engines are more or less platform agnostic between Win, Mac and Linux AFAIK.

                Btw, that would be an interesting question to the Valve Linux blog; the fraction
                code touched (let's say by means of lines) in order to accomplish the successful porting.

                Comment


                • Originally posted by entropy View Post
                  I said "Huh?" because you were comparing ports of a rather complex heap of code of modern engines to
                  countless "ports" of very old games which were mostly _complete_ "rewrites".
                  Those were comparably trivial games (technically) to rewrite from scratch and that does not tell you anything about
                  their "portability" (Maybe just that they were typically not portable at all).
                  OTOH, the largest part of the modern engines are more or less platform agnostic between Win, Mac and Linux AFAIK.
                  It seems you just have a strange idea that porting an application would in any way imply that the code has to be in any way portable at all. That is not the case, as you can see here: http://en.wikipedia.org/wiki/Porting

                  As for the triviality, I beg to differ. Firstly, games were developed by much smaller teams as well, back then (usually just one or two programmers). Secondly, where Windows and linux run on identical hardware, these older platforms often had quite different hardware characteristics, and it would sometimes require signifcant effort to reinvent the same graphics on a completely different platform.
                  I suggest you read this blog, to get an idea: http://popc64.blogspot.com

                  My point being: it's pretty sad that developers don't put in any effort anymore to support other platforms, or even different OSes on the same platform, where one day they would bother porting games to many different platforms, even if it meant rewriting the code from scratch, and even recreating the content (the original version of Prince of Persia was on Apple II, later versions such as MS-DOS and Amiga had updated graphics and sound effects).

                  Comment


                  • well this massive rewrites happens when you marry with microsoft technologies since they are not fan crossplataform or compatibility[mono is not an effort to change this but more like hey you can't sue me i support crossplataform check mono] but once you adopt open technologies this effort[or future efforts] are vastly reduced to the point of minor plataform adjust and compiler selection for X plataform.

                    if valve adopt let say Qt or GTK/ISO C++[x revision]/opengl/webkit/etc you can maintain 99% of your codebase plataform agnostic that will greatly reduce support cost and will help to implement fixes a freaking lot faster

                    Comment


                    • Originally posted by jrch2k8 View Post
                      well this massive rewrites happens when you marry with microsoft technologies since they are not fan crossplataform or compatibility[mono is not an effort to change this but more like hey you can't sue me i support crossplataform check mono] but once you adopt open technologies this effort[or future efforts] are vastly reduced to the point of minor plataform adjust and compiler selection for X plataform.
                      You have to put things in the proper perspective though.
                      The Source engine was developed in the early days of DX9 and programmable shaders. At this time, OpenGL had no standardized shader support whatsoever (and OpenGL never got standardized support for SM1.x hardware at all, while this was one of the primary hardware targets of HL2). It simply wasn't possible to write a game like Half Life 2 with OpenGL at that time, unless you wanted to include a separate render path for all hardware out there. Doom 3 tried, and failed. Apart from being more than a year late, the hardware compatibility left a lot to be desired, and Doom 3 only ran properly on a small selection of midrange-to-high-end Radeons and GeForces, where Half Life 2 was very scalable and even ran on DX7-class IGPs.
                      The Source engine is still used today on a variety of DX9+ hardware, while Doom 3 is nothing but a bad memory (and Rage didn't improve much on that... again late, poor hardware support, generally not a very decent game technically).

                      Today the situation is quite different: DX11 is nearly 3 years old, and OpenGL has more or less caught up. AMD, nVidia and Intel all have OpenGL 4.0+ support now, and shaders have been covered quite well with GLSL.

                      Comment

                      Working...
                      X