OSNews

Would you care to elaborate on what you meaning with "At least OpenGL support is now available on the Windows version"? I've used OpenGL with Steam on Windows for years, so forgive me for being a little confused

I meant with Half Life 2 type games; portal, etc. using the Source engine.

Steam doesn't use Direct3D or OpenGL. The games that use OpenGL using engines that support it.

Okay. Thank you for the clarification I know Counter Strike (old engine) supports OpenGL. I don't know about the other games.

Did they announce OpenGL support for the Windows port? There was another game had a Mac port but no OpenGL mode, which did prevent it from running well under Wine - UT3 (no Linux port either, *grumbles*).

I really hope they add OpenGL support to the Windows version - that's all I really need for a wine port (Steams works great under Wine, and so do most OpenGL based games I've tried).

It's pretty much assumed OpenGL will be on the Windows version.

My guess as to why Valve including OpenGL in Source is to make their engine more attractive to third party developers so they can license it.

Third party devs might also want to make games on the PS3.

I was thinking to myself that Steam on Android phones would be a good way to compete with XBoxLive on WP7 phones. I think there would be a lot of interest in that sort of app.

The problem here is that Linux isn't a single platform. It's software anarchy.

Agreed, and I think calling Linux or GNU/Linux a platform is flawed. Ubuntu, Fedora, Mandriva... these are the operating systems and platforms, mostly compatible at the source level and based on similar components, but mostly incompatible at the binary level. If I were a game developer wanting to target an alternate platform that isn't Mac, I'd target one particular Linux-based platform: Ubuntu. It's effectively the de facto standard these days, and most people using other similar oses know enough to symlink certain libraries or do whatever else they'd need to do to make it work. Target one, the community will make the rest work if they want to, and if you're going after the desktop market, it makes sense to target the prime desktop os in that category.

Actually they are fully compatible at source code level and mostly compatible at binary level. You'd be surprised to see the amount of software in binary form perfectly capable of running on a large variety of GNU/Linux distributions. It's a myth that there is a major binary incompatibility among the GNU/Linux distributions.

You are correct, sir. But the biggest stumbling block I see most times is getting that code or binaries going by legal, relatively hassle-free means. For many users without programming/coding skills, it means waiting for the company to release them-- especially for a client app.

Yes, reliance on DirectX over OpenGL is a common chokepoint, I think. If only all devs stuck to OpenGL... but I think profit and financial incentive is hindering that (yes, most likely from a particular company we all know).

WINE works quite well for ideal situations, yes. I remember it was the only way I could get certain NWN modules installed (i.e., off the disc).

But I'd like to work with a native installation as much as I can.

I love how everyone says it's a myth. I guess those of us who've dealt with said incompatibilities are halucinating then?
There's one, and only one, certain way to make a binary compatible across Linux platforms, and that is to statically link it. Otherwise, you can easily find that your software works well on one and not on another, typically due to a difference in the way the libraries are compiled that can expose a bug in one or more places that you might not have ever encountered, nor could encounter, on your development machines. Even if that problem goes away, you still have different package formats to deal with and, even among the same package format, different platforms name their packages differently sometimes so you need to compensate for that in your package dependencies. Even if all binaries were miraculously compatible tomorrow, that would only eliminate one problem for software deployment and release. And that's just software, the driver situation is far worse.
I'm not hating on Linux, but the facts can't be avoided. I use Ubuntu, it's my desktop os of choice, but that's no reason to be blinded to the facts. *Mostly compatible* is not good enough for software deployment across Linux platforms, which is why I would officially support only one. In that way, a standard exists and compiling multiple versions, multiple packages, multiple repositories can be avoided. There's no reason to go out of the way to make it not work on others, but I wouldn't guarantee that it worked if I were developing something closed. Since the various linux platforms will never standardize (and why should they?) a de facto standard is the next best thing.

There's no standard API across distros and there is no common system directory structure. System libraries are inconsistent across distros as well. No standard distribution package either.

The binary compatibility that exists works best for command line programs.

Binary compatibility doesn't mean an app will work - there are many other dependancies that must be filled - including certain libraries, and usually specific versions of those libraries. That can lead to nightmares getting a binary to work, that was compiled for another system - even if they are technically compatible at the binary level.

The Debian family of distros has done quite well, yes. I suppose I could see companies releasing a .deb package. But really, I'd be just as happy to see it done the way Bioware did NWN (which has been messed up somewhat when ownership switched from Atari to EA).

And then that developer, or developers, need to test it on each of those platforms and make sure it, you know, actually works as expected. Linux *is* software anarchy if you choose to view GNU/Linux as one platform. I've already stated why I feel that this view is flawed, it is not one platform but a diverse set of platforms aiming at particular niches and/or configurations. GNU/Linux, if viewed as an operating system, is ridiculously fragmented and cluttered. Break it down, however, and you see that Ubuntu, Fedora, etc are the operating systems and targeting one is much like targeting any commercial os out there.

1. They could be using Cider, which can wrap DX calls into OpenGL

2. If the games are _only_ available through Steam (very likely) then I will have no part of it. DRM? No thanks. I'm used to my Mac games being honest.

How should companies authenticate proof of purchase, then? I agree DRM implementation so far is evil and awful but I'm not sure trialware methods currently used by indie companies will work for all.

Steam at least keeps pirates off of multiplayer servers. Companies like Valve shouldn't have to spend money on bandwidth for pirates. They provide a convenient way of purchasing games, I really don't think the DRM is a big deal.

I agree DRM is not the ideal route, but what games out there don't use some sort of DRM today?

Between this and direct2drive I think Mac users will have a pretty good selection of new games.

Anyone who is really into games these days should buy a console though.