Geothermal. Last I checked, Hawaii was a chain of volcanic islands. And geothermal is (iirc) a very stable, reliable power source, good for base load.
Between geothermal, solar (it's very bright in Hawaii), tidal, and wind (lots of off-shore for off-shore wind farms), Hawaii would be a really good place to test (and prove) renewable power. It even has an economic edge there it won't have elsewhere - shipping oil, coal or natural gas to Hawaii by boat is far more expensive than shipping it by ground elsewhere.
When I need a codename for one of my game projects, I go to Wikipedia and scroll through the article of the day until I find a word I like. It usually has some mostly-symbolic association with the intent of the project, but sometimes not even that.
Project Overture was to be my first "real" game. Metaphorically, it would be "the overture to the symphony that will be the rest of my work". But that tells you nothing about what it actually was - "Project #1" would have worked just as well.
Project Glacier uses it ironically - the game is all about speed, while glaciers are known for moving at, well, glacial speeds.
Project Horizon and Project Hammerbeam had no connection at all. They just sounded kind of badass. That's what a good codename should be - it is intended to hide the purpose of the project, not reveal it.
(and no, none of these have been finished yet. Hammerbeam was to be a cooperative effort, but my partner quit. Overture was far, far too ambitious - I'd like to make it someday, but it's effectively dead as well. Horizon is an open-source project, currently on hold due to personal reasons. Glacier has a (slim) chance of becoming a commercial project, but otherwise is likely to be canceled.
Buffer has several meanings, as most words in most languages do.
It could be a render buffer, what you insistently seem to think I'm saying. That's where it renders frames to a queue before displaying them. This buffer is desirable, of at least one frame, as it prevents the frame from being copied to the display while it is being updated, resulting in "tearing". Additional pre-rendered frames are mostly undesirable. However, this argument is pointless because THAT'S NOT WHAT I'M FUCKING TALKING ABOUT.
What I said, and what anyone with a three-digit IQ could have figured out from context, is that having an extra few milliseconds where the renderer doesn't actually have to do any work means that if the workload suddenly spikes, you maintain a sufficiently-high framerate. Say some big particle effect gets used somewhat-often, but not constantly, and it cuts your framerate by 20%, and let's also assume you're on a 60Hz display. If you run at only 60fps on average, you will normally be updating the screen on every cycle - 60fps. But when that particle effect comes on, it drops to 48fps, which means you start missing display refresh cycles. Not good. But if you have a "buffer", say 80fps, when that particle effect comes on you still render at 64fps, and thus never miss a refresh. It's a safety buffer. Like how, when driving, you don't drive 5cm behind the car in front of you - you drive several meters behind, so if the car in front slams on his brakes for some reason, you have time to do so as well before you slam into him.
Finally, I'll note that "buffer" can also mean "one, or something, that buffs", but that's not important.
Ah, that explains things. Valve does present fairly often at SIGGRAPH. If it's coming up, they may have written this short blog post as sort of a lead-in.
You're talking "algorithm optimization". Using binary searches instead of looping through the whole array, for instance. I imagine those are all pretty cross-platform - O(n log n) will beat O(n^2) no matter what operating system you're on.
But games tend to care a lot more about performance, and so they do a lot lower-level optimizations than most applications bother with.
For instance, which is faster - rendering a triangle strip, or a triangle fan (ie. glBegin(GL_TRIANGLE_STRIP) or glBegin(GL_TRIANGLE_FAN))? It's entirely possible that one is faster on a different OpenGL implementation.
Or is it faster to run a DoF shader per-object, or run it as a post-process effect? Again, depends more than a bit on the GL implementation.
Kernel-level, does malloc() work best with 1kb chunks? 4kb chunks? Any size at all? Is it more efficient to just malloc() massive 128mb chunks and use internal functions to allocate and manage it? Depends, I suppose, on your malloc() implementation, which last I checked was different between Linux and Windows.
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" games on Steam - check the "Family" genre. I actually ended up with several by buying several "everything this company made" packs.
You suppress evidence gathered from illegal searches because it is a huge discouragement to performing illegal searches.
Let's say I'm a cop, and I suspect someone is responsible for the murder I'm investigating. I've got zero evidence besides a really good gut feeling. Can't get a warrant.
If I break in and search the place anyway, I could find the evidence I need (or even plant the evidence I want found, because I'm a loose-cannon cop not playing by the rules). But it's illegal, and the judge will throw it out immediately and prevent the jury from seeing it. So I don't do that - I question witnesses, maybe follow the guy around a bit, until I have enough evidence for a warrant.
If I know the judge will just slap me on the wrist and say "bad cop, don't do it again", do you think I'm going to think twice about my break-in search?
That's why judges are allowed to suppress illegally-obtained evidence. Because that's the only way to truly enforce police evidence laws. Because it is better that ten guilty men go free than one innocent man be thrown in prison.
I hate laws like this, which are so needlessly specific to handle ephemeral trends. Why didn't they just make it illegal to impersonate other people? Who profited by lobbying against that?
Actors. Actors often have to "impersonate" another person - see anyone acting in a biographical movie, for instance.
So once again, we can blame Hollywood! Yay Slashdot!
A judge can "suppress" evidence within the courtroom. That's fine, that's even necessary. If evidence was illegally obtained, say through an illegal search and seizure, of course a judge should prevent it from being used in court. I may think it was wrongly suppressed in this case, but it's the law.
But Samsung isn't trying to release this evidence in court. They're releasing it for public knowledge. They may be doing so in an attempt to overturn the inevitable ruling, but a judge cannot prevent a company from releasing its own property in a case like this (national defense, maybe, or if it was "stolen" information, but that's not this case).
So it's logical to conclude that Samsung believes: a) The judge is completely biased, possibly bought off, perhaps just a rabid Apple fangirl b) That they cannot win this case, and will need to appeal, therefore: c) Pissing off the judge cannot hurt them, as this judge would never rule for them anyways, and d) Anything they can do to improve their odds on appeal is worthwhile
So Samsung is playing the long game. They've given up on this battle, and are already preparing for the next one.
In fact, if they can show that this judge ruled more harshly in retaliation for doing something that is completely legal, they improve their odds of getting it overturned on appeal. So they should actually be trying to anger this judge (through entirely legal means, of course).
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.
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.
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.
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 playing Half-Life, the OpenGL renderer looked much better on my computer (it seemed to use better texture filtering than DirectX). However, it somehow caused an audio problem when underwater - you couldn't hear anything. So for the levels with water in it, I generally switched over to DirectX just for a bit. It was most likely just because the renders stuck to default settings, not bothering to set a texture filter mode, and the drivers decided on different defaults for each.
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.
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.
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.
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).
Did you ever play it at launch? Or perhaps after the initial patches?
Up to the Sniper vs Spy Update, it was amazing. It started going downhill after that (I quit after the War! Update, and never returned). And all the things I see from a now-outsider's perspective only reinforce that decision.
If I ever run out of games to play, I might go back to it, see if there's mods to bring it back to the way it was back in '09.
Crysis does that deliberately, trying to make camouflage an important gameplay element. It somewhat succeeds - the AI gets confused by camouflage sometimes, and that's not including your magic invisibility thing. So if you play it right, you can turn it into a weapon for you, instead of against you.
Other games do it simply to look "cinematic". Doesn't work well.
If you read some of the developer's papers on Team Fortress 2, you'll note that they were obsessed with visual identification. Every class was identifiable by silhouette alone, they used special lighting algorithms to emphasis object edges, and they maintained consistent color schemes, with players and important items being both high-saturation and high-contrast compared to backgrounds.
That all went out the window somewhere around the time the first promo items were released, but it's still something more developers should learn from.
An urn is just a jar. Not as visually unique as a coffin. A coffin may be just a box, but it's a very particular box. An urn can really be any shape.
Not to mention the fact that, at least in the western world, coffin burials are far more common than cremation, and thus death is more strongly associated with coffins than urns.
If the rumors (which I personally don't believe) of a Linux-powered Steam Console are true, that's incentive enough.
The Ouya (or however the fuck it's spelled) managed to get somewhat-mainstream promises of support, and that's for a low-power, crowd-funded Android console. You take Valve, possibly the best game studio on the planet (and definitely the best self-funded studio), who already has a large-scale relationship with most publishers and has experimented with acting as a publisher itself, and have *THEM* launch a console? It would get publisher support. Activision would jump on it. Zenimax (id + Bethesda) would jump on it. Rockstar would jump on it. THQ, if it manages to survive that long, will jump on it. EA would take some time, but if it gains market parity with Microsoft and Sony, EA will come around. Square Enix and Konami might move slowly (Japanese developers rarely move onto American consoles immediately).
Now, most likely, the Steambox rumors are just that - rumors. But it's within the realm of possibility, and it would make Linux ports more attractive (porting from Windows to Linux is hard - porting from a semi-proprietary Linux to Linux is easy).
Even if you've never bought a discrete card, you've used one, integrated either onto the motherboard, into the northbridge, or on the processor itself.
One of my earliest computers had an ATI Rage 3D right on the motherboard. Later, I used one with an nVidia chipset, which had (I believe) a 7000-series GPU integrated with the northbridge. My current laptop has an Intel GPU right on the processor (it also has a discrete nVidia card). Unless your computer literally does not have any video capability, it has some sort of graphics "system". Quite possibly an Nvidia chip (they're the largest, followed by AMD, Intel, PowerVR, and a few others (I think Matrox is still around)).
I just restarted Steam and saw this (again - had already RTFA and commented). It of course popped up saying "the EULA and Privacy Policy have changed, please read and agree (if you disagree, you cannot continue)". Then it showed me the new EULA.
Or rather, it tried to. The text box was blank. I clicked through before I thought to grab a screenshot, otherwise I'd have one hell of a technicality should I ever want to sue them.
Slashdot Mirror
Geothermal. Last I checked, Hawaii was a chain of volcanic islands. And geothermal is (iirc) a very stable, reliable power source, good for base load.
Between geothermal, solar (it's very bright in Hawaii), tidal, and wind (lots of off-shore for off-shore wind farms), Hawaii would be a really good place to test (and prove) renewable power. It even has an economic edge there it won't have elsewhere - shipping oil, coal or natural gas to Hawaii by boat is far more expensive than shipping it by ground elsewhere.
When I need a codename for one of my game projects, I go to Wikipedia and scroll through the article of the day until I find a word I like. It usually has some mostly-symbolic association with the intent of the project, but sometimes not even that.
Project Overture was to be my first "real" game. Metaphorically, it would be "the overture to the symphony that will be the rest of my work". But that tells you nothing about what it actually was - "Project #1" would have worked just as well.
Project Glacier uses it ironically - the game is all about speed, while glaciers are known for moving at, well, glacial speeds.
Project Horizon and Project Hammerbeam had no connection at all. They just sounded kind of badass. That's what a good codename should be - it is intended to hide the purpose of the project, not reveal it.
(and no, none of these have been finished yet. Hammerbeam was to be a cooperative effort, but my partner quit. Overture was far, far too ambitious - I'd like to make it someday, but it's effectively dead as well. Horizon is an open-source project, currently on hold due to personal reasons. Glacier has a (slim) chance of becoming a commercial project, but otherwise is likely to be canceled.
I don't say this often, but you're a moron.
Buffer has several meanings, as most words in most languages do.
It could be a render buffer, what you insistently seem to think I'm saying. That's where it renders frames to a queue before displaying them. This buffer is desirable, of at least one frame, as it prevents the frame from being copied to the display while it is being updated, resulting in "tearing". Additional pre-rendered frames are mostly undesirable. However, this argument is pointless because THAT'S NOT WHAT I'M FUCKING TALKING ABOUT.
What I said, and what anyone with a three-digit IQ could have figured out from context, is that having an extra few milliseconds where the renderer doesn't actually have to do any work means that if the workload suddenly spikes, you maintain a sufficiently-high framerate. Say some big particle effect gets used somewhat-often, but not constantly, and it cuts your framerate by 20%, and let's also assume you're on a 60Hz display. If you run at only 60fps on average, you will normally be updating the screen on every cycle - 60fps. But when that particle effect comes on, it drops to 48fps, which means you start missing display refresh cycles. Not good. But if you have a "buffer", say 80fps, when that particle effect comes on you still render at 64fps, and thus never miss a refresh. It's a safety buffer. Like how, when driving, you don't drive 5cm behind the car in front of you - you drive several meters behind, so if the car in front slams on his brakes for some reason, you have time to do so as well before you slam into him.
Finally, I'll note that "buffer" can also mean "one, or something, that buffs", but that's not important.
Ah, that explains things. Valve does present fairly often at SIGGRAPH. If it's coming up, they may have written this short blog post as sort of a lead-in.
You're talking "algorithm optimization". Using binary searches instead of looping through the whole array, for instance. I imagine those are all pretty cross-platform - O(n log n) will beat O(n^2) no matter what operating system you're on.
But games tend to care a lot more about performance, and so they do a lot lower-level optimizations than most applications bother with.
For instance, which is faster - rendering a triangle strip, or a triangle fan (ie. glBegin(GL_TRIANGLE_STRIP) or glBegin(GL_TRIANGLE_FAN))? It's entirely possible that one is faster on a different OpenGL implementation.
Or is it faster to run a DoF shader per-object, or run it as a post-process effect? Again, depends more than a bit on the GL implementation.
Kernel-level, does malloc() work best with 1kb chunks? 4kb chunks? Any size at all? Is it more efficient to just malloc() massive 128mb chunks and use internal functions to allocate and manage it? Depends, I suppose, on your malloc() implementation, which last I checked was different between Linux and Windows.
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" games on Steam - check the "Family" genre. I actually ended up with several by buying several "everything this company made" packs.
You suppress evidence gathered from illegal searches because it is a huge discouragement to performing illegal searches.
Let's say I'm a cop, and I suspect someone is responsible for the murder I'm investigating. I've got zero evidence besides a really good gut feeling. Can't get a warrant.
If I break in and search the place anyway, I could find the evidence I need (or even plant the evidence I want found, because I'm a loose-cannon cop not playing by the rules). But it's illegal, and the judge will throw it out immediately and prevent the jury from seeing it. So I don't do that - I question witnesses, maybe follow the guy around a bit, until I have enough evidence for a warrant.
If I know the judge will just slap me on the wrist and say "bad cop, don't do it again", do you think I'm going to think twice about my break-in search?
That's why judges are allowed to suppress illegally-obtained evidence. Because that's the only way to truly enforce police evidence laws. Because it is better that ten guilty men go free than one innocent man be thrown in prison.
I hate laws like this, which are so needlessly specific to handle ephemeral trends. Why didn't they just make it illegal to impersonate other people? Who profited by lobbying against that?
Actors. Actors often have to "impersonate" another person - see anyone acting in a biographical movie, for instance.
So once again, we can blame Hollywood! Yay Slashdot!
A judge can "suppress" evidence within the courtroom. That's fine, that's even necessary. If evidence was illegally obtained, say through an illegal search and seizure, of course a judge should prevent it from being used in court. I may think it was wrongly suppressed in this case, but it's the law.
But Samsung isn't trying to release this evidence in court. They're releasing it for public knowledge. They may be doing so in an attempt to overturn the inevitable ruling, but a judge cannot prevent a company from releasing its own property in a case like this (national defense, maybe, or if it was "stolen" information, but that's not this case).
So it's logical to conclude that Samsung believes:
a) The judge is completely biased, possibly bought off, perhaps just a rabid Apple fangirl
b) That they cannot win this case, and will need to appeal, therefore:
c) Pissing off the judge cannot hurt them, as this judge would never rule for them anyways, and
d) Anything they can do to improve their odds on appeal is worthwhile
So Samsung is playing the long game. They've given up on this battle, and are already preparing for the next one.
In fact, if they can show that this judge ruled more harshly in retaliation for doing something that is completely legal, they improve their odds of getting it overturned on appeal. So they should actually be trying to anger this judge (through entirely legal means, of course).
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.
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.
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.
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 playing Half-Life, the OpenGL renderer looked much better on my computer (it seemed to use better texture filtering than DirectX). However, it somehow caused an audio problem when underwater - you couldn't hear anything. So for the levels with water in it, I generally switched over to DirectX just for a bit. It was most likely just because the renders stuck to default settings, not bothering to set a texture filter mode, and the drivers decided on different defaults for each.
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.
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.
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.
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).
Did you ever play it at launch? Or perhaps after the initial patches?
Up to the Sniper vs Spy Update, it was amazing. It started going downhill after that (I quit after the War! Update, and never returned). And all the things I see from a now-outsider's perspective only reinforce that decision.
If I ever run out of games to play, I might go back to it, see if there's mods to bring it back to the way it was back in '09.
Crysis does that deliberately, trying to make camouflage an important gameplay element. It somewhat succeeds - the AI gets confused by camouflage sometimes, and that's not including your magic invisibility thing. So if you play it right, you can turn it into a weapon for you, instead of against you.
Other games do it simply to look "cinematic". Doesn't work well.
If you read some of the developer's papers on Team Fortress 2, you'll note that they were obsessed with visual identification. Every class was identifiable by silhouette alone, they used special lighting algorithms to emphasis object edges, and they maintained consistent color schemes, with players and important items being both high-saturation and high-contrast compared to backgrounds.
That all went out the window somewhere around the time the first promo items were released, but it's still something more developers should learn from.
And most importantly, you've used drivers for that graphics processor. Which could be exploited like this one.
Less graphically iconic.
An urn is just a jar. Not as visually unique as a coffin. A coffin may be just a box, but it's a very particular box. An urn can really be any shape.
Not to mention the fact that, at least in the western world, coffin burials are far more common than cremation, and thus death is more strongly associated with coffins than urns.
If the rumors (which I personally don't believe) of a Linux-powered Steam Console are true, that's incentive enough.
The Ouya (or however the fuck it's spelled) managed to get somewhat-mainstream promises of support, and that's for a low-power, crowd-funded Android console. You take Valve, possibly the best game studio on the planet (and definitely the best self-funded studio), who already has a large-scale relationship with most publishers and has experimented with acting as a publisher itself, and have *THEM* launch a console? It would get publisher support. Activision would jump on it. Zenimax (id + Bethesda) would jump on it. Rockstar would jump on it. THQ, if it manages to survive that long, will jump on it. EA would take some time, but if it gains market parity with Microsoft and Sony, EA will come around. Square Enix and Konami might move slowly (Japanese developers rarely move onto American consoles immediately).
Now, most likely, the Steambox rumors are just that - rumors. But it's within the realm of possibility, and it would make Linux ports more attractive (porting from Windows to Linux is hard - porting from a semi-proprietary Linux to Linux is easy).
Just idle speculation on my part.
Even if you've never bought a discrete card, you've used one, integrated either onto the motherboard, into the northbridge, or on the processor itself.
One of my earliest computers had an ATI Rage 3D right on the motherboard. Later, I used one with an nVidia chipset, which had (I believe) a 7000-series GPU integrated with the northbridge. My current laptop has an Intel GPU right on the processor (it also has a discrete nVidia card). Unless your computer literally does not have any video capability, it has some sort of graphics "system". Quite possibly an Nvidia chip (they're the largest, followed by AMD, Intel, PowerVR, and a few others (I think Matrox is still around)).
No, "Snakes on a Plane" didn't make enough money or have enough long-term pop culture impact to reference it.
"Ship-Rex" might work (punning off "shipwrecks" and "t-rex". It's a horrible pun, but it could work well enough for a "SyFy" channel movie...
I just restarted Steam and saw this (again - had already RTFA and commented). It of course popped up saying "the EULA and Privacy Policy have changed, please read and agree (if you disagree, you cannot continue)". Then it showed me the new EULA.
Or rather, it tried to. The text box was blank. I clicked through before I thought to grab a screenshot, otherwise I'd have one hell of a technicality should I ever want to sue them.