Valve Shares Performance Numbers On Port of Left4Dead 274
New submitter nschubach writes in with an update on Valve's progress porting one of their games to GNU/Linux. From the article: "One factor in creating a good gaming experience is throughput. This post discusses some of what we've learned about the performance of our games running on Linux. ... After this work, Left 4 Dead 2 is running at 315 FPS on Linux. That the Linux version runs faster than the Windows version (270.6) seems a little counter-intuitive, given the greater amount of time we have spent on the Windows version. However, it does speak to the underlying efficiency of the kernel and OpenGL. Interestingly, in the process of working with hardware vendors we also sped up the OpenGL implementation on Windows. Left 4 Dead 2 is now running at 303.4 FPS with that configuration."
nschubach adds "It seems there are good things coming out of this for both Operating Systems!"
Year of... (Score:5, Funny)
LINUX DESKTOP
Re:Year of... (Score:4, Funny)
Linux Desktop? Nope. Desktops are dying anyway, almost everyone has moved to laptops.
Year of the Linux game console, perhaps?
Re:Year of... (Score:5, Interesting)
This is unfortunate. Ever since I became a nomad (and switched to Apple) that I miss actually shopping for desktop hardware. Every time I enter a retail store and look at the high-end video cards I really really want to build a desktop, but it can't fit my luggage... The desktop PC is far from being dead and I am already missing it, I think it's gonna be one of those things that I will remember from early 21st century just like I miss tinkering with analog electronics in the 80s (no, I'm not old, I was born in that decade).
Rumor has it that Valve is building a console with PC hardware, so I wouldn't rule out that possibility. They feel that the Windows and Mac App Stores represent a threat to Steam as a third party, so this may be part of their strategy to build a platform of their own. Blizzard has expressed similar feelings, which makes sense if we consider the rumor that they had and probably still have a third party service like Steam planned for battle.net (at least according to the leaked schedules [techcrunch.com] which have been quite accurate, though battle.net third parties is overdue at this point).
Re:Year of... (Score:5, Interesting)
I think they aren't so much building a game console as they are building a spec for a Linux based gaming PC for everyone to get behind. That makes more sense to me. I, quite literally, only use Windows to play games. Every thing else I either do on my phone, tablet, or already just as easily could do under Linux. If they can make it easy for us hardcore gamers to transition to Linux, then I doubt any of us would bother with Windows again.
The only issue is support for all this cutting edge hardware I have. Linux is always a problem there, but if gamers start to flock, I hope so too will the companies that make our gaming hardware.
Re:Year of... (Score:4)
Games are the only reason I use Windows at home.
Re: (Score:3)
I love Linux. I've had some distribution or another set a second partition since the late 90s. It's great for basic usage and applications. Your average user will miss out on nothing by switching to Linux. But for me, it's not something I can use full time, try as I might. Games are a big part of it, but there are other things as well.
I'd say that the lack of Adobe's Creative Suite is a huge sticking point for me. I use just about every one of those programs on a near daily basis. It might work well enough
Comment removed (Score:5, Interesting)
Re: (Score:3)
The only "threat" the MS Appstore holds to Valve is the Cut The Rope, Angry Birds type of "gamers" that frankly wouldn't know WTF Steam was or that they even HAD those popcap style games in the first place!
Just an FYI, Popcap themselves were actually one of the first third-parties to sell on Steam. I remember when early versions of Steam listed every free game on Steam in your library. At the time, that was what, Lost Coast and Codename: Freeman?
Then Popcap came in, and had demos for roughly ten million games[citation needed]. It rather irritated gamers, having to scroll through so many games they don't actually have or care for. They fixed that in a patch a few weeks later.
There are a lot of other "casual" g
Re: (Score:2)
It's not just the box, it's also all the peripherals. A laptop has everything built-in.
Re: (Score:3)
There is a difference between your computer's desktop and a desktop computer.
Reports of the Linux Desktop's death have been greatly exaggerated.
Re: (Score:3)
Re:Year of... (Score:5, Insightful)
" Desktops are dying anyway, almost everyone has moved to laptops."
as a gamer I went this route.. once.. bought a pricey gaming laptop... too hot, always had to change thermal paste, didn't keep up well with the games. I gave up and built out a new desktop.
As long as thermal issues remain in computing and vendors refuse to standardize and allow upgrading of laptop components desktops sized computing will not die.
Re: (Score:2)
Sigh. Moron.
Nice of you to sign your posts when posting anon, but I don't think you're a moron at all ;)
I love laptops. They're portable & easy to take everywhere. I even do most of my work on one. That said, when I go home to play games, there is no way in the hot place that I want to game on a laptop. I don't need portability in my gaming, but I do need a non-mobile graphics card, full-size keyboard and mouse and multiple large monitors. Of course I can plug these into a laptop (except the graphics card, o
Re: (Score:2)
I'm guessing it was solid influence plus just taking a long ass time? I'm not anyone with a view into valve though, but my thoughts are that:
Valve is so big now that if they go "we're going to Linux" they can bring it en masse. Back when valve was relatively new that wouldn't have exactly happened like that.
Re:Year of... (Score:5, Informative)
Valve projects run on the basis of "work on what you think brings value to our customers and to the company", so someone would have to have decided "I think a Linux port is a good idea, so I will start working on one" and encouraged other people to join the project. All of their desks are on wheels, so people working on stuff can move their desks together - they just unplug from where they are and plug in where they go.
Valve has a flattened hierarchy, there are no managers. Team leaders aren't appointed, they just happen because the naturally turn out to be the team leader. Remuneration is based on perceived worth by your peers. Their employee handbook is an interesting read - the PDF of it was publicly available, last time I checked.
Re: (Score:3)
Gabe basically answered this already, Windows 8 is why.
Re:Year of... (Score:5, Funny)
My Debian brings all the beards to the yard
And they're like, it's better than yours
Damn right it's better than yours
I could fork it and I wouldn't even charge
Interesting bit from the article (Score:5, Informative)
What I found interesting was how much an improvement this is from their initial port.
Their very first version ran at a full six frames per second (167ms/frame). They've now gotten it up to 315 fps (3.17ms/frame).
That's some pretty impressive work. Pity the article is so light on the details of how they did it (I'll spare you reading the article: they found places where it ran slow due to the kernel, they found places where it ran slow making OpenGL calls, and they found places in the driver itself that ran slowly - that's about as much detail as the actual article gives you).
Re:Interesting bit from the article (Score:5, Interesting)
What I find really interesting is the fact that this port spurred impovements in proprietary OpenGL drivers, in close collaboration with manufacturers.
This push by Valve may benefit everyone, even people who never will use Steam.
Re: (Score:3, Informative)
Wrong, he said they only worked with Intel specifically on OSS drivers. They've been working with ATI and nVIDIA on PROPRIETARY drivers very much, and have made that very clear.
Re: (Score:2)
The article gives about as much detail as you need really. The heap stuff sounds familiar, I think they mentioned that they were going to optimise it pretty early on. It is nice that they've achieved such speed gains though, especially on the driver side.
Re: (Score:2)
I would have liked much more detail. What shaders were the most problematic to optimize? What sections of the code perform differently (the netcode? the AI? the animation?)
Valve normally goes into a lot more detail. I remember their TF2 art presentation going on and on about shader algorithms - lots of equations, and pictures showing the effect of each term.
Re:Interesting bit from the article (Score:5, Interesting)
I'm sure lots more details are coming.
Valve are doing a big presentation on their Linux adventures next week at SIGGRAPH (6th - 9th Aug)
Re: (Score:2)
Well, it is just a blog post - perhaps they'll do a more in depth presentation at a later point? :)
Re:Interesting bit from the article (Score:5, Informative)
Let's be careful with statements, please. They didn't say it ran slow due to the kernel or OpenGL, that is BS. They are acknowledging their own errors, not OpenGL's and not the kernels. They also did say exactly what they did to fix the situation.
I'll spare you on your details with the reality of what they said:
Their goals:
Performance improvements fall into several categories:
Modifying our game to work better with the kernel
Modifying our game to work better with OpenGL
Optimizing the graphics driver
The results:
An example of the first category would be changing our memory allocator to use more appropriate Linux functions. This was achieved by implementing the Source engine small block heap to work under Linux. The second category would include reducing overhead in calling OpenGL, and extending our renderer with new interfaces for better encapsulation of OpenGL and Direct3D.
The third category is especially interesting because it involves working with hardware manufacturers to identify issues in their drivers and, as a result, improving the public driver which benefits all games. Identifying driver stalls and adding multithreading support in the driver are two examples of changes that were the result of this teamwork. That's not a valve benefit, that's "all linux games" benefit.
Re:Interesting bit from the article (Score:4, Interesting)
Sorry, I sort of glossed over that distinction.
The problem is in how the code works with the kernel (or GL driver). That can be fixed either by reworking how the code calls it, or reworking how the kernel (or driver) works internally. I referred to this, ambiguously, as "problems with the kernel", not "problems working with the kernel".
As far as kernel stuff, they seem to have done it entirely on their side. I imagine most of it was memory allocation - Linux's malloc() has much different performance characteristics than Window's malloc(), and that's 90% of your kernel calls right there.
The GL stuff they fixed in both places. In some, they were using it in a sub-optimal way. Sometimes they had to work with the driver team to get it fixed in the driver.
Re: (Score:3)
I imagine most of it was memory allocation - Linux's malloc() has much different performance characteristics than Window's malloc(), and that's 90% of your kernel calls right there.
*twitch* malloc() is not a kernel call, its a library function only. man 2 brk.
Re:Interesting bit from the article (Score:5, Informative)
What I found interesting was how much an improvement this is from their initial port.
Their very first version ran at a full six frames per second (167ms/frame). They've now gotten it up to 315 fps (3.17ms/frame).
That's some pretty impressive work.
That happens on nearly every Engine port. For example - Mortal Kombat on the Playstation VITA Handheld Console.
I worked on the team porting Unreal from PS3 / XBOX 360 to PS Vita at Netherrealm Studios (which we did in house separate from Epic's efforts). We ported over a NULL driver and then got the basic graphics up and running. Our initial port ran at 6 FPS. The shipped game ran at 60FPS with frame syncing and 80-90FPS at Speed-of-Light (frame syncing off).
You write a lot of code quickly to just get things working and once they are, you figure out the bottle necks and optimize code and assets from there.
Re: (Score:2)
Efficiency (Score:3, Interesting)
Re:Efficiency (Score:5, Interesting)
Yea, I noticed several years ago, back when I used to play WoW and my computer could barely handle, that it would run faster in Linux on Wine with OpenGL than it would on Windows XP. I mean I'm talking ~5fps on windows to ~15fps with better graphics on Linux -- not really playable on Windows, barely playable on Linux.
Re:Efficiency (Score:4, Insightful)
Re: (Score:2)
Really? I never noticed any missing -- then again, I had the graphics settings as low as possible just to get the damn thing to run.
Re:Efficiency (Score:5, Insightful)
You may well be right, I'd be cautious in taking anything away from this particular article though, as Valve have made it quite clear now that they have a vested interest in seeing Windows fall as they see Windows 8 as a genuine threat to their existence if people start buying games directly from the Windows Marketplace rather than Steam. When they referring to Windows 8 as a general "Catastrophe" which is probably a bit of a stretch, even if it maybe is for them, then it's hard to see them as objective on this issue.
Not that this is likely to be an unpopular move here, nor is it necessarily a bad thing if a company like Valve is helping Windows fall a peg or two, but now Valve has a clear political motivation to attacking windows, it's hard to see anything anti-Windows they mention as necessarily objective. It's also quite possible that Valve's Windows engine actually just isn't well optimised, and that now that they're moving it to another platform it's given them chance to rewrite components that were long overdue for a rewrite. I believe at least some of the foundations and design of the Source engine actually stem all the way back to the Quake 1 codebase for example.
Re:Efficiency (Score:5, Informative)
Much of the engine design dates back to the Quake 2 engine, but none of the code does.
History time!
First came Quake, which was coded completely from scratch. Then came Quake ][, which was a significant overhaul and massive rewrite. Some of the code was saved, but the engine design itself was changed quite a bit. Both of those engines were written by id Software.
Valve licensed the Quake ][ engine, and improved on it, adding a new renderer (a DirectX one, IIRC, but they kept the OpenGL and software renderers) and several other nice features. They used this for Half-Life, Team Fortress Classic, Counter-Strike 1.6, etc., and also offered it for relicensing under the name GoldSrc.
Over the years and years it took to make Half-Life 2, they rewrote literally the entire engine. Not a single line of code remains from Quake ][. They rewrote the renderer (several times), added all kinds of animation goodies, integrated Havok physics, and so on. But they kept the same basic client/local server/server design, the same general layout. It's much like how GNU made the basic Linux toolset - they copied the design of UNIX, but did not use any code from it.
Valve has continued to use and upgrade this engine, calling it Source to confuse everyone. They've offered it for license, and at one point were seen as a decent competitor, but they've really fallen behind in the post-UnrealEngine 3 world. I half-suspect they'll be either doing a total engine redesign, or giving up and licensing someone else's engine.
Re: (Score:2)
I highly doubt they will license another engine given their recent Source Filmmaker [sourcefilmmaker.com] work. Thats an impressive piece of technology and I have a hard time seeing them let it all go to waste.
Re: (Score:2)
This has always been true in my experience. Quite a few Windows games running under Cedega were faster for me in Linux than on Windows with the same hardware. Native ports are an even bigger improvement; I found everything from NWN to Quake3Arena much faster on Linux than on Windows.
Re:Efficiency (Score:5, Insightful)
They weren't expecting it to run more efficiently *given the level of work they invested*. They've sunk years of work into making the Windows version run quickly. Getting a Linux port to run faster, only months after getting their initial port running (the first running Linux version ran at 6 fps under the same test), is impressive.
Re: (Score:2)
With this, it seems more like just a knee-jerk reaction to not liking either Windows 8 or the Surface brouhaha.
Well, that is what it is, and that is what is expected. Valve/Steam is in the business of desktop gaming. Windows 8 (and Gnome 3) will steer people away from desktop computers on to tablets and other devices primarily intended for consuming and not input heavy work.
If Gabe didn't react, I would be more worried.
Re: (Score:2)
Really? People will play stuff like WoW and Skyrim on tablets? Somehow I doubt it.
Re: (Score:2)
Really? People will play stuff like WoW and Skyrim on tablets? Somehow I doubt it.
You missed the point, being that if people convert to tablets, there won't be any future Skyrim class games.
Re: (Score:2)
I suspect they'd still exist, but just on consoles, which is sad.
Re: (Score:3, Funny)
Uh, use of linux will surely lead to us running out of a natural resource which cannot be replenished. Frames.
By burning more frames per second we risk our childrens future, those poor bastards will have to view TV on e-ink at this rate.
Re: (Score:2)
If Windows users aren't playing it anymore then it was a crap game to begin with. Good games stand the test of time and even get run in emulation 30 years later. Don't waste my time or money with dreck.
Plenty of people still play Super Mario knockoffs (or the real thing in emulation). Mario never went anywhere.
Great (Score:5, Funny)
Can we bring those improvements to Mac OS X?
Re: (Score:2)
Not terribly impressive considering that Microsoft has relegated Apple to single digit market share for about 20 years.
Re:Great (Score:5, Interesting)
Windows loves developers, OS X hates developers, Linux IS developers.
We developers knew this for a long time.. (Score:5, Informative)
This approach was proven again very succesful with mobile hardware, where vendors such as Qualcomm, PowerVR or Tegra or ARM (Mali) produce graphics chips that comply with OpenGL but at the same time use the higher level abstaction of the API to their advantage, by supplying very different backends each (Immediate Rendering, Deferred and Tile Based Deferred) as means to improve performance (per watt and silicon space) to levels much higher than the desktop counterparts.
Added to that, programming games under Linux is a joy for those used to it, as the tools are fantastic (command line scripting, gdb with hardware watchpoints, valgrind, strace, etc) and the fact the OS manages the heavy load of games much better. Many companies I worked with, and even big ones such as Naughty Dog (makers of Uncharted) develop their games primarily under Linux, even if the final versions are released for Windows, Mac and Consoles.
Re: (Score:3)
I know I am going to come off as a 'shill' but MS tools rock (I am not talking about their frameworks). It is the one thing that holds me to windows these days. All those tools you mention are available in windows and usually better polished. Valgrind compaired to say using boundschecker. You goto valgrind and bisect issues, boundschecker puts you right on the offending line that they think either overwrote memory or leaked. .
You're going to come off as an MS shill because you are flat out lying. Valgrind tells you exactly what line is offending.
char *p = malloc(8);
p[10] = 42;
Let valgrind run that code and it will immediately tell you that the source filename and linenumber that p[10]=42; is on along with a callstack backtrace. Ditto with leaked memory, reads of uninitialized memory etc.
Whats the point of 300+ FPS (Score:3)
Rather then going for broke and getting as much FPS as possible, why don't game developers focus on optimizing the experience for a SOLID 60 FPS, that is, instead of peaking at 300 FPS in one scene, and then dropping to 45 FPS in another, strive for a constant frame rate.
If 60 fps does not tax a rendering system, then focus on MORE content in the scene, such as more particles or physics effects which enhance the gaming experience.
Maybe this is just some raw development figure, but there is absolutely no point in dumping as many frames as possible to a screen which only refreshes a given number of times per second.
I mean if someone came out with a car that outputs 300hp when driving 60 mph, I wouldn't be impressed, so why do I care how many frames are rendered between screen refreshes.
Re:Whats the point of 300+ FPS (Score:5, Insightful)
This was 300fps on an *extremely* powerful system. The GeForce 680 is the most powerful single-GPU card on the market, and the 3930K is one of Intel's top consumer chips. I myself have a 660 and a 3610, weaker versions of the ones they used, and I can max out every game I have.
Getting 300fps on that means that, on a system a tenth as powerful, you get 30fps without dropping the graphics settings. Valve just doesn't chase the extreme high-end hardware - they don't bother adding more particles and such that make it look better only on a fraction of a percent of systems. Valve has perhaps the best knowledge of what real-world users are gaming on, thanks to the Steam Hardware Survey. So they can make an informed decision as to whether it is worth it to have the artists come in and add yet another layer of detail that will only be seen on the newest and most expensive computers.
That said, 120hz monitors seem to be rising in popularity, making rendering at 120fps a worthwhile goal. And it's often good to have a buffer of 10-20fps or so, because the amount of stuff you have to render isn't constant. In combat (with all the particle effects, explosions, flying debris, etc.), it often drops by 10%-20%, which can put you below 60fps if you're running at 70-80 normally.
Re: (Score:3)
You misread GP. When he said buffer, he means having an extra 10-20 FPS more than necessary. Headroom would have been a better word IMO.
Re: (Score:2)
Wrong kind of buffer. He's referring to a buffer as in a safe-zone -- A buffer against performance hiccups. If your frame rate drops below 60 FPS even briefly, any system with VSYNC enabled instantly drops to 30 FPS to prevent screen-tearing until the FPS goes above 60 again.
OpenGL vs DX (Score:2)
I've noticed the different in speed of OpenGL versus DirectX in the past when the first versions of Google Earth came out. You could choose between OpenGL and DX to run the program. OpenGL was very smooth whereas DX's FPS could be counted on your fingers.
Irony (Score:5, Funny)
It'd be highly amusing to me if, in a few years time, Windows users are keeping a copy of Linux around because "I need it for the games" :)
Re:What does it tell you? (Score:5, Interesting)
Re:What does it tell you? (Score:5, Interesting)
Re: (Score:2)
Re:What does it tell you? (Score:4, Funny)
Does the openGL driver/port have the same graphic detail as the directX version?
You think they don't know how to benchmark their own game?
Re:What does it tell you? (Score:5, Insightful)
Clearly not. They give a bare number that doesn't indicate whether it is a maximum FPS or an average FPS. They provide neither the test setup (screen resolution, detail settings, etc), nor meaningful analysis of overall performance. For example, if the average FPS is lower on one platform, but the variability is also lower, the actual user-perceived performance will be better. No meaningful details are provided, just some ePeen number which is abstract of context. The statistician in me weeps.
Re:What does it tell you? (Score:4, Insightful)
That only shows that they fail at communicating the results. Not that the result itself is bogus...
Re:What does it tell you? (Score:5, Informative)
Re:What does it tell you? (Score:5, Insightful)
Re:What does it tell you? (Score:5, Insightful)
It's not "clear" at all. Just because they didn't provide such details doesn't mean they don't exist. Absence of evidence is not evidence of absence.
Valve is an exceptionally competent developer of high performance, low-level graphics software. The article says "The data is generated from an internal test case". It's reasonable to assume this internal test case is specifically designed for, oh I dunno, TESTING. Which means it's designed to put the different rendering pipelines through the exact same gauntlet (or as close as can be managed).
Why would you think that them running the test at inconsistent resolution/detail settings is even a remote possibility? Do such obvious test practices REALLY need to be spelled out for you?
Yes, they reduced the test data to a simple number (I thought it was pretty obvious this represented "average" FPS). It's an easier discussion point. What of it? It's a blog post, not a scientific paper.
Re: (Score:3)
Yes, it's mentioned in one of the replies in the comments.
Re: (Score:2)
Re:What does it tell you? (Score:4, Insightful)
So I don't know why anyone should be surprised at this, Linux has always been OpenGL, Windows DirectX, so having Linux do OpenGL better isn't surprising, anymore than Windows doing DirectX, its just what the platform is made for is all.
As a counterpoint, TFA said that their OpenGL port of L4D2 on Windows ran faster than the DirectX version.
Re: (Score:3)
Re: (Score:2)
So I don't know why anyone should be surprised at this, Linux has always been OpenGL, Windows DirectX, so having Linux do OpenGL better isn't surprising, anymore than Windows doing DirectX, its just what the platform is made for is all.
Assuming I understand you correctly, I should perhaps have rephrased this:
What I find more interesting, to be honest, is that Open GL is (slightly) outperforming Direct 3D on a windows/nvidia box.
To:
What I find more interesting, to be honest, is that Open GL on a windows/nvidia box is (slightly) outperforming Direct 3D on the same box.
Re: (Score:3)
Re:What does it tell you? (Score:5, Informative)
OpenGL sits over the top of DirectX on Windows
No, it doesn't. That was the plan when they developed Vista, but it was scrapped after an outcry from half the industry. The OpenGL driver is just as low level as the DirectX driver on Windows.
Re:What does it tell you? (Score:5, Insightful)
Er, no, it actually doesn't.
Microsoft had planned to do so in Vista (they actually wanted to run old versions of DirectX on top of DX10, then the newest), but they scrapped that plan well before release after half the game industry, most of the professional graphics industry, and the graphics card companies themselves rose up in arms (Nvidia was actually planning on circumventing it, offering direct OpenGL).
So on any actually-released version of Windows, OpenGL is as low-level as DirectX.
Re: (Score:3)
This is not true - OpenGL is still a native driver. Microsoft wanted to cripple OpenGL in this way, but the CAD industry pushed back through Khronos and Microsoft agreed to retain native driver access.
Microsoft still hasn't updated the Windows OpenGL library bindings in something like a decade, so OpenGL developers all have to use the extension mechanism to access all of the new features.
Re: (Score:3)
It isn't surprising for anyone who knows DX and OpenGL well, but it is surprising for game developers and other graphic intensive users since the "everybody knows" that graphics on Linux sucks.
Re: (Score:3)
Probably that, when dealing with GPU-limited things like framerates in a moderately intensive OpenGL application, a substantial portion of your performance is going to come down to the togetherness between your application and the GPU vendor's drivers, so working with said vendors might help...
Re:What does it tell you? (Score:5, Insightful)
This is actually a mundane sort of thing in cross platform development. Your other "ports" aren't just a money pit. They allow you to stress your code in ways you might not have thought of. Typically the bugs you find in secondary platforms improve your product on it's primary platform.
Re:What about quality? (Score:4, Informative)
From what I understand, OpenGL has more features because they support extensions where Direct3D has to wait for Microsoft support. Granted, this requires that the developer actually use those extensions. The blog is rather light on details/screenshots.
Re: (Score:2)
Re: (Score:2)
Re:What about quality? (Score:5, Interesting)
Re: (Score:2)
With the latest iterations of OpenGL there is pretty much feature parity. Some of the bleeding edge tessellation and such deals don't have feature parity and bloom doesn't have as much impact but to be honest they look shit to me most of the time anyways.
Bloom can make otherwise totally photo-realistic games look cartoony. Which is great, if you're into that, I'm not.
However I think Valves involvement is even making those issues go away, since they're even working on OpenGL itself.
Re: (Score:2)
They're basically the same at this point.
There have been times when either was ahead (early versions of Direct3D lacked many features, while some versions of Direct3D were a leap ahead of OpenGL). As of right now, they're pretty much tied for features.
That does not, however, mean that different versions of a game, using different renderers, look the same. But that's because the game uses different code to do it, and if they don't take care to make them look the same, they often will not.
Back when I was play
Re: (Score:2)
Huge FPS numbers actually are very useful for a variety of reasons. FPS is highly variable during gameplay, the higher the general FPS, the better your FPS will be when the game gets swamped with moving particles...which means it might not slow to a crawl at the most intense and exciting parts of the game...something that is particularly important in a multiplayer game like L4D.
Not to mention of course the fact that we are able to see a relatively accurate measurement of efficiency between two platforms, w
Re: (Score:2)
It seems to me that being faster than necessary on one piece of hardware means that, all else equal, it will be noticably better on some slower piece of hardware.
As long as the benchmark is not done with minimum system that is capable of running the game.
Re: (Score:3, Informative)
Re: (Score:2)
Since almost all LCD displays only refresh at 60Hz, no matter how frequently the graphics card's framebuffer is being redrawn, the only thing a higher framerate would get you is the ability to turn off vsync and buffering without having any tearing issues. So you might get slightly better latencies maybe?
People with 120 Hz 3d LCDs could benefit from higher frame rates, though. But I don't think it's likely that _anyone_ is gaming on a display that's actually capable of showing >250 FPS. Maybe such displa
Re: (Score:3)
CRTs can do 250+Hz, but good luck finding one these days outside of a flea market.
Re: (Score:2)
It's just a benchmark. It's not saying "These extra 200 fps are going to make your game sooo much better."
They're talking about the increased performance in opengl rendering in general that you get with Linux.
Re:Ehhhhhh. (Score:5, Insightful)
Very few gamers can even notice a difference between 60-100 let alone over 100.
They will, however, notice the difference when a sudden spike in activity causes the fps to drop to half or a quarter of that. Rendering speeds are highly dependant on what is being rendered.
A game running at 240fps can happily suffer a 75% drop without any noticeable impact, while a game which just barely makes 60 fps will not.
Re:Ehhhhhh. (Score:5, Insightful)
Render rates far above 60fps means that I don't have to treat my machine like an xbox just because I decide to do some gaming with it.
It also means that I can likely get away with a much less powerful system and GPU and still have acceptable performance.
I can use less machine to get the job done.
Re: (Score:3)
When you have TONS of explosions going off, TONS of lighting effects, you want the MINIMUM frame rate to stay ABOVE 60.
BY targeting such a high frame you have a nice SAFETY MARGIN for when the engine needs to start rendering additional (special) effects.
No offense, but you're an idiot.
Go play some BF:BC2 or BF3 on High Quality until you learn why 60+ fps is important.
Re: (Score:3, Interesting)
If you haven't noticed, Valve stopped making games a while ago and instead became a content whoring system. One game every 5+ years doesn't make you a game developer IMHO.
Re: (Score:2)
Its what blizzard did, of course I no longer consider them a game developer after diablo 3.
Re:Episode 3 (Score:5, Funny)
Its what blizzard did, of course I no longer consider them a game developer after diablo 3.
I'm not familiar with that game; did you mean Auction House Tycoon?
Re: (Score:2)
http://en.wikipedia.org/wiki/Valve_Corporation#Games [wikipedia.org]
They tend to release at least one game a year.
Re:Valve is big on Linux (Score:5, Funny)
% wine Steam.exe
Yeah, look at them all.
Re:Valve is big on Linux (Score:5, Funny)
Re:Valve is big on Linux (Score:5, Funny)
I was wondering why the difficulty level increased with each version.
Re: (Score:2)
Well the result would be 0 FPS because DOS couldn't even load the game menu, let alone the information to render a single frame of a modern HD game.
Re: (Score:2)
Sure, why not? HX Dos Extender supports Win32 binaries and OpenGL. Although it's only software rendering, so I don't think you'd get much in the way of FPS.