LWN: Comments on "Valve: Steam’d Penguins"

Valve: Steam’d Penguins

i3839 — Sat, 28 Jul 2012 22:39:23 +0000

Ten years too late.

Plenty of Non-Free Android Apps.

gmatht — Sat, 21 Jul 2012 11:40:52 +0000

We can already advocate Android for these purposes. It is even a Linux, though not a Valve/GNU/Linux I suppose. :)

Valve: Steam’d Penguins

hummassa — Sat, 21 Jul 2012 10:51:03 +0000

> Legally I'm not sure where fan fiction falls.

Legally, every fan fiction is a derivative work- meaning it can only be created with the original work's author permission. The rules' words are something like "a transformation of the original work or a work that uses its characters, settings or general mise-en-scene." IIRC

Valve: Steam’d Penguins

Wol — Fri, 20 Jul 2012 19:42:56 +0000

Fan fiction can actually be a major problem for the author ...

For example, Terry Pratchett quite openly says on the fan forums he frequents, "NO fan fiction". It's not that he's against it per se, but he is (quite rightly) nervous that someone will post fan-fic, and then he'll use it because he doesn't remember reading it and thinks he made it up - or, more likely - that he'll use a similar plot and get accused of stealing the fan-fic story.

So the forum moderators and posters basically have a choice - ban fan-fic and welcome the author, or allow fan-fic and drive the author away.

Terry doesn't particular care which way a forum goes, but he does care that forums he frequents abide by his rules.

Cheers,
Wol

Valve: Steam’d Penguins

elanthis — Fri, 20 Jul 2012 05:20:10 +0000

> You are out of touch with recent developments. For one thing, OpenGL currently dominates 3D gaming

Nowhere did he or anyone else claim that OpenGL wasn't widely used. What he claimed (and almost every other game developer around, including those who exclusively use OpenGL) is that OpenGL is a crappy API compared to D3D. Just like Linux nerds claim that Windows popularity has nothing to do with it having technical superiority, OpenGL's popularity has nothing to do with its having technical superiority.

> Otherwise, OpenGL is completely uncontested in the rapidly growing phone and tablet market,

So, OpenGL is the only option on those platforms, and "yay OpenGL!" D3D is the only option on XBox, and "damn you lock-in!"

> and is also PS3 and Nintendo.

Complete lie. Nintendo does NOT use OpenGL in any capacity. Not a single Nintendo console is even _capable_ of running OpenGL 2.x+, as Nintendo has never released a console with shader support (the upcoming WiiU will be their first), and the specialized hardware in the GC/Wii and the 3DS are not based on OpenGL's fixed function pipeline. PS3 does have a stripped down incomplete GL ES library, but no serious game uses it. Every real PS3 game uses a proprietary hardware-specific Sony API.

People use PS3 as a point in OpenGL's favor all the time because they read on Wikipedia that "PSGL" is a thing. Not one of these people are actual PS3 game developers. For the love of God, stop making claims on things you don't actually use in real life.

Valve: Steam’d Penguins

iabervon — Thu, 19 Jul 2012 20:46:30 +0000

It seems to me like RMS's feelings are described in the Free Software Definition, where he lays out what the freedoms are for. It seems critical to me that the purpose of software is functionality, rather than artistic merit (or entertainment). As you move away from functional works towards works for art's sake, the freedoms make less sense, although there is middle ground like art assets, whose purpose may be "to give the appearance of wood" (i.e., a functional aspect of the effect of the work they are in) or may be artistic on their own. But, for most of the reasons that RMS has talked about for GPL-style licensing, the goals don't make sense when you're talking about Zork or Monkey Island and you've separately taken care of the "I can't play it on a modern computer" issues.

Valve: Steam’d Penguins

iabervon — Thu, 19 Jul 2012 20:15:37 +0000

That was what I meant by my "writing it from scratch" note; you can write a new ending, or you can rewrite the whole story, but you can't just change the ending and include the rest of the book by itself. (In fact, for high school assignments, I ended up writing a "lost section" for The Sound and the Fury and a total rewrite of The Cask of Amontillado, but I obviously didn't turn in a complete copy of The Sound and the Fury, normal but for the addition of a section in the middle somewhere, and I didn't include any of Poe's original text, even the quoted dialog.)

IIRC, the characters and titles are considered separate works from the novels themselves, and authors have certain rights with respect to characters they created; Harry Potter fan fiction wouldn't be derivative of the book series if it didn't use any of the text, but would be derivative of the fictional universe. I haven't looked into the particular rules, but they're probably somewhat murkier and certainly different (since "fair use" is going to be an entirely different set of things).

Valve: Steam’d Penguins

sorpigal — Thu, 19 Jul 2012 11:18:08 +0000

> it's hard to imagine someone having a pressing need for Harry-Potter-with-a-different-ending

It's hard to imagine a need, but it's not hard to imagine: enter fan fiction, where I assure you "Harry-Potter-with-a-different-ending" has been done many times. In all cases, however, it's an author's original work, even though the plot and characters are thoroughly "inspired by" the original.

Legally I'm not sure where fan fiction falls. Use of the characters without permission probably gets you in trouble, as does use of the title names, and it's almost always going to be derivative.

Valve: Steam’d Penguins

Cyberax — Thu, 19 Jul 2012 11:05:41 +0000

> Arg, you have got to be kidding. Avoiding pointers as much as possible through the use of integer handles is a huge advantage for OpenGL in terms of, for example, avoiding segfaults and being able to debug easily
LOL. Cause getting mysterious GL errors is SO much better.

Oh, have I mentioned that GL handles are only 32-bit?

>The mutable object thing... that's a big meh for me. So... a texture handle goes through a table in the driver and can therefore refer to any kind of supported texture? Big deal.
Yup, just a little nice performance-killer. Nothing big.

And you'll get a special effects Oscar if you try to modify an object while it is being used by a shader.

Valve: Steam’d Penguins

njwhite — Thu, 19 Jul 2012 10:35:21 +0000

> I wouldn't be surprised if, in the future, we had top-quality open-source
> game engines, as well as vast libraries of art assets that may be freely
> used and tweaked in various ways, but games were generally not open
> source.

I actually wouldn't mind this as an outcome, really. For example ScummVM and the various interactive fiction interpreters all treat the games this way, and the end result is pretty great. Good quality games, no worries about lack of source for what's executing on the PC (and great quality code,) and the actual 'game' itself *can* be hacked around if your care enough (though redistribution may be an issue, but generally I think I'm OK with the original author having some control over this.)

I've never been too sure about RMS' view of different classes of works being treated differently by the copyright system, but perhaps this is an example of where it makes some sense. But yes, I remain unsure, and am certainly sway-able.

Valve: Steam’d Penguins

Pawlerson — Thu, 19 Jul 2012 07:41:43 +0000

Valve said they'll be encouraging others to port their games as well.

Valve: Steam’d Penguins

paulj — Thu, 19 Jul 2012 07:25:14 +0000

you're required to write something new from scratch (perhaps relying on the reader's knowledge of the original text, but never including that text).

Note that if you overtly rely on the other text, e.g. by having your characters or plot be based on that of the other, you will still be creating a derivative work of the first. In which case the copyright holder of the first work will have a copyright over the derived work.

Valve: Steam’d Penguins

rgmoore — Wed, 18 Jul 2012 23:36:23 +0000

Yeah, because that could never happen if it weren't Free Software.

Valve: Steam’d Penguins

iabervon — Wed, 18 Jul 2012 23:17:15 +0000

If you don't like how Harry Potter ends, how do you go about changing it? Even if the novel you'd like to change is "Someone Comes to Town, Someone Leaves Town" (released under a Creative Commons license), you aren't allowed to, because it's (quite reasonably) the "by-nd-nc" version. In general, if you want to modify any piece of fiction, you're required to write something new from scratch (perhaps relying on the reader's knowledge of the original text, but never including that text). Of course, this is not a big Free Software issue, because it's hard to imagine someone having a pressing need for Harry-Potter-with-a-different-ending, whereas Linux-where-my-device-works is a common need. Even though there's a open-source-style need for Harry-Potter-but-it-fits-in-my-pocket, that's a qualitatively different sort of grant of rights than the GPL or BSD license applied directly to a novel would be.

Valve: Steam'd Penguins

daniel — Wed, 18 Jul 2012 22:20:58 +0000

"I'm inclined to agree with the LWN comment page's great provoker on the questionable viability of high-production-value games as open source projects."

Apparently you haven't been following Blender Foundation's recent projects.

Valve: Steam’d Penguins

daniel — Wed, 18 Jul 2012 22:18:21 +0000

"The main roadblock is poor support by most vendors (except for Nvidia"

AMD Catalyst is pretty darn good these days. (The only reason I don't use it is because Xorg Radeon is good enough.) Also, Intel's 3D stack has improved immensely. Not buggy and I'm even beginning to see something resembling frame rate out of it.

Valve: Steam’d Penguins

Del- — Wed, 18 Jul 2012 22:17:37 +0000

>Even after OpenGL3.0 it wasn't uncommon to have special codepaths to handle a couple of not-yet-standardized vendor extensions.

It is entirely up to you whether you use those extensions. Feature parity with D3D10/11 was already with OpenGL 3.2, OpenGL3 is supported by any relevant driver on linux these days. What you seem to ignore is that the extensions is one of the mechanisms that allow OpenGL to advance, it is a way to thread water with new functionality. If it works out well and developers like it, it has a high probablity of being added in the next iteration of OpenGL. If it bothers you, then simply target a specific OpenGL version. That was even worse with D3D where targeting version was standardised only with D3D10 as far as I recall.

>It's just that everybody have resigned themselves to the inevitable. We're not getting Longs Peak so we might as well shut up and continue to deal with the legacy crap.

No they don't. The pointer issue has been openly discussed, you just need to go where the discussion is at. You seem to believe that you know what opengl5 should look like. Hence, I challenge you to share your views here:
http://www.opengl.org/discussion_boards/showthread.php/17...

Valve: Steam’d Penguins

daniel — Wed, 18 Jul 2012 22:11:31 +0000

Other than that, tools for D3D development (shader debugger, IDE support, etc) are superb.

Perhaps you need some of this. In any case, I just started doing serious shader development. Development stack: Mesa + Xorg Radeon. Elapsed time to get a decent per-pixel Phong shader up and running: about four hours from start to finish, and that was only because I had next to no clue what I was doing at the time. (What's a uniform??) I especially like the way you can dump the IR (intermediate representation) for the code to the console just by setting an environment variable.

Valve: Steam’d Penguins

daniel — Wed, 18 Jul 2012 21:55:09 +0000

I suppose that Microsoft had no choice but to back off their efforts to undermine OpenGL support on Windows in part because they failed to convince some of the major CAD vendors to port to DirectX. After all, what is the point of supporting two different 3D backends when you don't have to? Much of high end CAD still runs on Unix workstations. There is no way the CAD vendors would have left those guys in the lurch.

Valve: Steam’d Penguins

daniel — Wed, 18 Jul 2012 21:45:53 +0000

The problem with OpenGL is that each vendor gave their own OpenGL stack. Which means that as a game designer you are not targeting 'OpenGL API' you are programming for: Intel's OpenGL API, Nvidia's OpenGL API, ATI's OpenGL, etc etc. Each vendor had subtle differences and different bugs to work around. Not to also mention that in order to be 'cutting' edge you had to deal with all the vendor-specific proprietary extensions.

For year or two I develop exclusively on the open source Mesa + Radeon stack. Yes, it means I need to use a few extensions but big deal. It also means I run a little slower, but again big deal, the hardware is still stupidly fast. Both those issues pale next to the fact that I'm running a stack that I can count on, and that integrates well with the rest of my environment. I can say with complete confidence that this stack has become a joy to use.

Here's a sample

Notice the anisotropic filtering on the ground plane. Notice the ridiculously high triangle count. It's running at 60 FPS at high resolution on a $50 GPU. Big shoutout to everybody involved: Mesa guys, Radeon devs, Xorg, Freetype, GCC... It's not so much that these guys made this possible, as they made it pleasant.

Now I'm just waiting for MSAA to land to perfect this stack. Not every far away. Last time I booted Catalyst was more than a year ago.

Valve: Steam’d Penguins

ssmith32 — Wed, 18 Jul 2012 21:32:12 +0000

> many of the older titles (especially those developed by third parties) aren't going to be ported to Linux.

In all fairness, I don't know too many gamers jumping up and down to get their hands on old titles. So as long as Valve expands the program to new games going forward - it should be fine.

Since I think it's safe to assume any core libraries they re-use from game to game got ported with L4D2.. and any new code will just be written with portability in mind, doing this as a moving-forward strategy makes sense, while backporting does not.

So there is hope. OTOH, I'm not a gamer, so I could be totally misunderstanding the market.

And the console/windows app backstop rumors do make some sense.. Valve was posting positions for hardware (and I mean actual hardware, not driver) engineers and designers.

Valve: Steam’d Penguins

daniel — Wed, 18 Jul 2012 21:30:04 +0000

We STILL have to use object names (handles) instead of direct pointers. Object creation is STILL not atomic and objects are mutable.... With D3D10/11 things are braindead simple: you have a pointer to a device object and you simply call its methods. And you can do this from multiple threads. Created objects are immutable (a 2D texture can't magically become 1D texture).

Arg, you have got to be kidding. Avoiding pointers as much as possible through the use of integer handles is a huge advantage for OpenGL in terms of, for example, avoiding segfaults and being able to debug easily, and at the same time maps better to the hardware, which can't use those DirectX addresses directly I hope you know. If you want pointers and methods, write your own. It's easy. And you get exactly what you need instead of whatever Microsoft decided you should have.

The mutable object thing... that's a big meh for me. So... a texture handle goes through a table in the driver and can therefore refer to any kind of supported texture? Big deal. At least, it provides a nice friendly way to represent empty/free objects. On balance I would rather have this than not. It is certainly not a reason to get worked up, one way or the other.

As you are no doubt aware, the OpenGL DSA extension is maturing, which will be a great help for multi-CPU rendering and also a modest boost to single thread rendering performance. This would have been the centerpiece of Longs Peak, but let's be honest, that would have been rash. "Measure twice, cut once" and let's not throw out any babies with our bathwater.

Executive summary: I don't know what you're going on about, or why.

Valve: Steam’d Penguins

daniel — Wed, 18 Jul 2012 21:07:02 +0000

The basic problem of OpenGL is that it is a hugely bloated interface, and as a whole doesn't fit well either modern hardware or modern games. However, it generally supports all GPU features (and often more than DirectX thanks to extensions), so it's mostly a performance, correctness and ease of use problem. The fact that almost all Windows games use DirectX when they could instead use OpenGL is pretty telling (and no, there are no roadblocks to using OpenGL on Windows).

You are out of touch with recent developments. For one thing, OpenGL currently dominates 3D gaming, with the exception of the XBox walled garden and the PC segment where Microsoft narrowly failed to kill it off. Otherwise, OpenGL is completely uncontested in the rapidly growing phone and tablet market, and is also PS3 and Nintendo. No game company in their right mind would start a new project that fails to support OpenGL.

Modern OpenGL, 3.0+, has been cleanly factored into two parts: 1) a "legacy profile" that will eventually move to a separate library and 2) core OpenGL consisting of drawarrays, Vertex Buffer Objects, shader support, and various other facilities that map well to modern GPU hardware. There is no way you can describe OpenGL as bloated. It now ranks as one of the cleanest and most tightly defined libraries for anything, anywhere. And frankly, it is also very nice to have the friendly old legacy support around as an option, which in many cases is the quickest way to try out some new idea, then if it works out you put in the (modest) extra work to port it to the modern pipeline.

Valve: Steam’d Penguins

mordae — Wed, 18 Jul 2012 20:47:07 +0000

I believe this is a safety of kinds for Valve. If things go downhill and Microsoft forbids third party app stores in Windows 8, Valve will need to get into the console business.

Valve: Steam’d Penguins

dlang — Wed, 18 Jul 2012 20:02:37 +0000

no, most novels are not open source

you almost never get the text in a format that is modifable (even e-books frequenly come with DRM and/or in .pdf), let alone in it's "preferred format" for changes

it's just about unheard of for you to be given permission to redistribute the text, let along permission to modify and then redistribute the text, even if you have the text in a form you can edit.

"open source" does not just mean that you can see the contents.

Valve: Steam’d Penguins

Cyberax — Wed, 18 Jul 2012 19:51:32 +0000

> How is that relevant at all. Directx10 is not available on Windows XP.
And who cares? D3D10 is still better.

> "Because Direct3D 10 hardware was comparatively rare after the initial release of Windows Vista and because of the massive installed base of non-Direct3D 10 compatible graphics cards, the first Direct3D 10-compatible games still provide Direct3D 9 render paths.
You can't have it both ways. The WinXP era hardware simply lacked support for OpenGL3-level functionality. And OpenGL3-capable hardware had D3D10 support at the time of Vista launch.

However, if we're talking about D3D9 vs. OpenGL2 then D3D9 not only wins, but SLAUGHTERS OpenGL completely. Mostly because any real-life complex OpenGL codebase had to have special code paths FOR EACH HARDWARE VENDOR.

Even after OpenGL3.0 it wasn't uncommon to have special codepaths to handle a couple of not-yet-standardized vendor extensions.

>OpenGL started deprecating legacy stuff with 4.0. The criticism from 3.0 (long peaks ordeal) became rather silent with subsequent quick releases from Khronos.
It's just that everybody have resigned themselves to the inevitable. We're not getting Longs Peak so we might as well shut up and continue to deal with the legacy crap.

>Today I see little reason to favour D3D.
Except that quite a lot of Longs Peak stuff is _still_ not completely there.

OpenGL is STILL dependent on hidden thread-local rendering context. We STILL have to use object names (handles) instead of direct pointers. Object creation is STILL not atomic and objects are mutable.

Don't believe me? Then look at parallel code that attempts to create and manipulate OpenGL objects from different threads. Or just read stuff like this: http://hacksoflife.blogspot.com/2008/02/creating-opengl-o...

With D3D10/11 things are braindead simple: you have a pointer to a device object and you simply call its methods. And you can do this from multiple threads. Created objects are immutable (a 2D texture can't magically become 1D texture).

Valve: Steam’d Penguins

jedidiah — Wed, 18 Jul 2012 19:45:48 +0000

ALL novels are open source. I think you are getting your terms and concepts confused.

Valve: Steam’d Penguins

Del- — Wed, 18 Jul 2012 18:38:03 +0000

>It's very well known in the industry. D3D10 is a very nice and clean API, it could be implemented with Gallium3D by one developer in a short amount of time.

How is that relevant at all. Directx10 is not available on Windows XP. This quote is quite telling:

"Because Direct3D 10 hardware was comparatively rare after the initial release of Windows Vista and because of the massive installed base of non-Direct3D 10 compatible graphics cards, the first Direct3D 10-compatible games still provide Direct3D 9 render paths. Examples of such titles are games originally written for Direct3D 9 and ported to Direct3D 10 after their release, such as Company of Heroes, or games originally developed for Direct3D 9 with a Direct3D 10 path retrofitted later in development, such as Hellgate: London or Crysis."

ref. http://en.wikipedia.org/wiki/Microsoft_Direct3D#Direct3D_10

>They've thrown away all the legacy fixed pipe crap and instead implemented everything with programmable shaders.

OpenGL started deprecating legacy stuff with 4.0. The criticism from 3.0 (long peaks ordeal) became rather silent with subsequent quick releases from Khronos. Today I see little reason to favour D3D.

Valve: Steam’d Penguins

iabervon — Wed, 18 Jul 2012 18:06:42 +0000

They'll obviously need to use at least a different OpenGL implementation, if not a different 3D API entirely, in order to get the Portal games to link. The AI engine in those games refuses to link with the usual implementation on Linux. (And by "refuses to link", I mean, "acts passive-aggressive and then threatens to release neurotoxin.") The Half-Life series should be no problem, though.

Valve: Steam’d Penguins

iabervon — Wed, 18 Jul 2012 17:57:40 +0000

You don't see a lot of open-source novels, either. For that matter, there's a community of people writing top-quality-for-the-genre games who generally release them for free, and they mostly don't release source to games, although they release source to libraries they wrote for games. (This being interactive fiction, where the modern authors have in many ways surpassed what Infocom did in their day.) There's a large extent to which not releasing the source for a game is motivated by the desire to avoid spoiling surprises or giving away the ending or the secrets.

I wouldn't be surprised if, in the future, we had top-quality open-source game engines, as well as vast libraries of art assets that may be freely used and tweaked in various ways, but games were generally not open source. (And I wouldn't be surprised if the engine/art/game architecture ended up being designed intentionally to make the game obviously not subject to engine or art license requirements, much as RMS's email is not subject to Emacs's license requirements.)

Valve: Steam'd Penguins

drag — Wed, 18 Jul 2012 16:57:57 +0000

Voluntary or not is really not what you should be looking at.

Game programming is like everything else. If you want to do a good professional job you have to have good professionals, or their equivalent.

That means people with ten years experience being artists/writers/programmers/ or whatever that are able to work for 5-8 hours every day for several months to get something done in a reasonable time frame.

This sort of thing is going to cost money no matter what. It's expensive and people need to make a living and be able to support themselves.

Raising money for software projects not anticipating using copyright law to create artificial scarcity has always been a challenge, but it should be possible. Kickstarter may be a start, but it's going to require more then that I think.

Valve: Steam’d Penguins

drag — Wed, 18 Jul 2012 16:16:31 +0000

> Since the anti-trust case in 1998, Microsoft have become more subtle in the way hurdles are laid out.

Microsoft learned that they have to play the 'big corporate' game of pay offs and supporting popular initiatives even if it means supporting corrupt-to-the-core stuff. (which is the vast majority of things).

> The lack of native support for OpenGL is one such subtle hurdle, yes you can circumvent it, but is is an annoyance and extra burden none the less

Hardware/drivers provide their own OpenGL stack anyways. This is the way it's always worked for OpenGL. The whole 'Second rate OpenGL' thing is a bit of a red-herring. By the time Microsoft Vista came out OpenGL already fell out of favor.

ID was the only company actually seriously using OpenGL long before Vista. Other game engines supported OpenGL back-ends, but it wasn't for mainstream gaming.. it was more a of a specialty item. (like some Arcade machines ran Linux OpenGL)

The problem with OpenGL is that each vendor gave their own OpenGL stack. Which means that as a game designer you are not targeting 'OpenGL API' you are programming for: Intel's OpenGL API, Nvidia's OpenGL API, ATI's OpenGL, etc etc. Each vendor had subtle differences and different bugs to work around. Not to also mention that in order to be 'cutting' edge you had to deal with all the vendor-specific proprietary extensions.

With ActiveX you only had one vendor to deal with. This means that you didn't have proprietary extensions. It is consistent and worked just about the same regardless of what video card the user happened to have.

This is exactly the same thing that Linux needs. A consistent API, which hopefully we will get with decent open source drivers. It's the only way to get OpenGL working consistently on all Linux machines. Nvidia's stack is so much better then the OSS one that anything OSS supports so will Nvidia. That is the only proprietary OpenGL driver for Linux that is worth a damn.

Valve: Steam’d Penguins

shmerl — Wed, 18 Jul 2012 16:08:34 +0000

OpenGL 4.x is not bad at all. The main roadblock is poor support by most vendors (except for Nvidia). Microsoft is guilty indirectly, since they pushed DirectX, which caused most manufacturers not to provide high quality drivers. Junky drivers don't allow even the best API to work as expected.

Valve: Steam'd Penguins

tialaramex — Wed, 18 Jul 2012 15:23:05 +0000

I think the present popularity of Kickstarter projects with a CC or GPL output is suggestive that "free culture" is expanding.

Hollywood movie budgets remain beyond the scope of these projects, for now, but the right video game project could definitely raise a million dollars on Kickstarter. A million dollars can pay for a lot of that necessary but rarely voluntary talent needed for "high production values" while keeping the results Free-as-in-speech.

Valve: Steam’d Penguins

Cyberax — Wed, 18 Jul 2012 13:28:27 +0000

>Now, do you have any information supporting that d3d is superior to opengl in any way? If not, why the heck do we have d3d at all.
It's very well known in the industry. D3D10 is a very nice and clean API, it could be implemented with Gallium3D by one developer in a short amount of time. They've thrown away all the legacy fixed pipe crap and instead implemented everything with programmable shaders.

Other than that, tools for D3D development (shader debugger, IDE support, etc) are superb.

Valve: Steam’d Penguins

leoc — Wed, 18 Jul 2012 13:24:05 +0000

No OS licensing fees...

And if it is successful, Microsoft, Sony, Apple, and Nintendo will probably sue them using some dumb patents as a pretext to shut down competition.

Valve: Steam’d Penguins

Del- — Wed, 18 Jul 2012 13:20:03 +0000

Hm, less misleading than your post I would say. You cherry pick a couple of statements from the wiki which contains lengthy information and elaborations on the exact same points. It is a wiki you know, consider spending your efforts correcting the statements you believe to be erroneous or misleading instead of misleading readers here.

The Windows Vista beta clearly signalled that Microsoft smelled OpenGL blood, OpenGL was planned to be a second rate citizen. The outcry on the opengl forum probably reached you too. From my recollection Microsoft never came out with any re-assurance, developers had to test later releases to find out that windowed opengl apps could be used with aero desktop. I am not at all sure Mircosoft would have yielded had not Vista been such a flop. This was at the time when game developers started to show interest for OSX. If you put your own money on a new game engine for windows, would you dare put your money on opengl, or would you make sure you had d3d covered? Sometimes it is enough to scare people into submission you know.

Since the anti-trust case in 1998, Microsoft have become more subtle in the way hurdles are laid out. The lack of native support for OpenGL is one such subtle hurdle, yes you can circumvent it, but is is an annoyance and extra burden none the less. It means lack of fall-back should the customers video driver miss functionality. It means low or no integration with other tools or api's on the platform. Moreover, the xbox only supporting all those other windows native developer tools is a rather strong incentive to go with the Microsoft tools all the way on windows, on xbox you will need to do the effort anyway.

Now, do you have any information supporting that d3d is superior to opengl in any way? If not, why the heck do we have d3d at all.

Valve: Steam'd Penguins

mpr22 — Wed, 18 Jul 2012 12:43:43 +0000

Yes, because there are coherent model for monetization of those things by intermediaries - the obvious ones being to sell support contracts for the software or manufacture hardware that uses the software. A "high production values" video game comes with a whole bunch of audiovisual material that probably isn't usefully monetizable by intermediaries, but still needed an awful lot of polishing and attention-to-detail to reach the desired standard. (And even if it was monetizable by intermediaries, there's the question of whether the resulting supply of money would allow you to hire a voice actor people have actually heard of.)

Valve: Steam'd Penguins

Otus — Wed, 18 Jul 2012 10:41:58 +0000

> Achieving the standards classified as "high production values" in respect
> of today's video game market requires an awful lot of specialist labour[.]

Isn't the same true for all software (at least)? There's a lot boring work
in creating a kernel or libc or video player - in addition to the non-boring
parts.

Are you saying those things are just easier to monetize as free software?

Valve: Steam’d Penguins

k3ninho — Wed, 18 Jul 2012 10:14:13 +0000

> ...And just maybe a preparation for a rumored Valve/Steam console.
No OS licensing fees, lowering their costs to build a device supported by a free-to-play/pay-for-accessories model - this is the important part. In their shoes I'd consider including an Android userspace for movies and music, to save Steam over-reaching themselves.

>The final burning question is: Will Team Fortress 2 be ported? And will Linux gamers get Linux themed hats? Because that's what it's really all about.
If Left 4 Dead 2 is coming, then the Source engine is coming over, so the free-to-play Hat Simulator will be ported, too. I would expect some joke about Red Hats and Fedoras in there - but the Ubuntu platform doesn't have a link to hat-wearing. Space helmet?

K3n.