ITS FINALLY HAPPENED! Steam for linux!

[Silicate Wielder]

Okay guys the time has finally come! for those of you running linux or ubuntu for that matter Steam has finally made its way to our linux desktops without the need for that pesky wine windows layer!

you can get it here: http://store.steampowered.com/about/
Ubuntu WIKI: https://wiki.ubuntu.com/Valve

[Rayquaza]

Looks awesome. Though I'll still stick with the Windows version in my opinion :) A larger range of games and a lot more higher graphics are common, although I won't be surprised if Linux does well considering it's game database is growing rapidly. But I just love how the only Linux machine they mention is ubuntu. Not even a reference to Mint or Debian :D

[Axw_JD]

And it runs like shit! With most games not available and developers unwilling to port over because of the low market share (which is the main reason why the steam box is linux based. Other than cost, valve is doing everything in their power to force devs to port their games to linux).

And to add icing to the cake, graphics performance in Linux is years away from its Windows counterpart.

[Silicate Wielder]

Well, have you tried intalling the updated video drivers? I updated mine, and it was laggy at first but it straightened out after a bit :)
I thought they might have at least one freetoplay game, I was wrong :(

[Axw_JD]

Yes I have, and with latest stable drivers, as well as community ones, game performance is, at best, 40-50% that of the exact same game under Windows 8 on the exact same hardware.

[HunterSteele]

valve is doing everything in their power to force devs to port their games to linux
Of course if they're "forced" to port their games to Linux, the ports will be extremely poor.

[TigerBoy]

When I can play the games I want, with equivalent performance, and without having to constantly coax the system into working optimally and investing masses of time researching how to work around the latest glitches, maybe I'll get excited. I like (and use) linux for some things, but it is presently far from being a painless low-maintenance tool for my gaming (and other) needs.

[Axw_JD]

Of course if they're "forced" to port their games to Linux, the ports will be extremely poor.

Which is exactly part of my point. Devs are not rushing out to port their games to Linux because in most cases is not worth it. The few that are doing it, do so under pressure (and possibly money) from valve, or studios that can't possibly go much lower in customer satisfaction anyways.

And there's a lot more to performance than just porting. If its standard C/C++ code, porting is just a matter of recompiling the source code with a different compiler (for games that don't use DirectX, which is only a fraction of PC games).

[Sugaree]

Steam for Linux has been out for a while now. At least a few months. I find that it runs wonderfully on Debian, but there's still lots of flaws running on Ubuntu.

Of course, you're not going to see a triple A game get ported to Linux, but there's still plenty of other games from smaller developers that are worth the time. On top of that, Valve is working on porting all their games to Linux and have already completed Half-Life 2 (and the episodes), Left 4 Dead 2 (possibly 1 also), and will most likely be porting over Counter-Strike: Source and Global Offensive. They can't really force devs to start making linux ports, but they can certainly highly encourage it like they do for Mac.

[TheMatrix]

(for games that don't use DirectX, which is only a fraction of PC games).

Even then, it should (in an ideal codebase) still be possible. A good game engine abstracts the specific details of the graphics, with the possibility of having multiple backends.
Apparently, most programmers don't want to take the time to write an OpenGL backend to their engine(I can't blame them, that takes ages). And why should they -- the same sells even if you don't have multi-platform support.

[Axw_JD]

Even then, it should (in an ideal codebase) still be possible. A good game engine abstracts the specific details of the graphics, with the possibility of having multiple backends.
Apparently, most programmers don't want to take the time to write an OpenGL backend to their engine(I can't blame them, that takes ages). And why should they -- the same sells even if you don't have multi-platform support.

Actually there are a lot of things wrong with OpenGL. It does a little too much stuff for you, which means it isn't as flexible or as powerful as DirectX. Plus some standard features of DirectX (Standard as in part of the HAL) are not part of the OpenGL standard and instead use hardware-specific implementations, which makes it nigh impossible for some games to be ported (some features might not even have a hardware-specific implementation for a good portion of the customer base).

On top of that, OpenGL is only needed if you are looking at Linux or Mac compatibility. None of the consoles use or support it (the PS3 supports a modified subset), while with DirectX you get Xbox 360 support for free.

[TheMatrix]

Actually there are a lot of things wrong with OpenGL.
I'll admit that it has its flaws. Especially since every single implementation is probably different -- ATI, nVidia, etc. all have their own versions of OpenGL. The API (should be) the same, but whether a feature works as expected depends entirely on how good the vendor's library and drivers are.

It does a little too much stuff for you, which means it isn't as flexible or as powerful as DirectX.
Perhaps, but that depends on exactly what you intend on doing with it. There is a tradeoff between ease-of-programming and flexibility. And it seems that OpenGL does just fine in most cases.

Plus some standard features of DirectX (Standard as in part of the HAL) are not part of the OpenGL standard and instead use hardware-specific implementations, which makes it nigh impossible for some games to be ported (some features might not even have a hardware-specific implementation for a good portion of the customer base).
Well then that's just bad programming. The only thing (again, in an ideal codebase) that should be hardware-specific is a (hopefully) modular backend for the various drivers. The Irrlicht engine, for example, does that.

On top of that, OpenGL is only needed if you are looking at Linux or Mac compatibility.
It works on Windows, too. And if you have your own operating system someday, the open standards of OpenGL shouldn't make it too hard to implement.

None of the consoles use or support it (the PS3 supports a modified subset), while with DirectX you get Xbox 360 support for free.
Well, it depends on your intended target. If you want to only distribute on Microsoft platforms, then I guess you might as well use DirectX. But if you want to distribute on multiple platforms, then it's only logical to support OpenGL.

By the way, the PS3 supports OpenGL ES, which is probably a more complete implementation. But I don't know -- I've never looked at developing for the PS3 yet.

[Axw_JD]

Perhaps, but that depends on exactly what you intend on doing with it. There is a tradeoff between ease-of-programming and flexibility. And it seems that OpenGL does just fine in most cases.

It doesn't. Current version of OpenGL is, at best, as easy to program as DirectX 9, but much less flexible than said version of DirectX. Now, which version of DX are we on right now? I'll let you do the math.

Well then that's just bad programming. The only thing (again, in an ideal codebase) that should be hardware-specific is a (hopefully) modular backend for the various drivers. The Irrlicht engine, for example, does that.

There is nothing that should be hardware specific in DirectX or OpenGL. That's the whole point of having a HAL (Hardware Abstraction Layer). Thats why you see most devs using DirectX and almost nobody using OpenGL (at most, some do it as a -pretty much useless- option).

Well, it depends on your intended target. If you want to only distribute on Microsoft platforms, then I guess you might as well use DirectX. But if you want to distribute on multiple platforms, then it's only logical to support OpenGL.

By the way, the PS3 supports OpenGL ES, which is probably a more complete implementation. But I don't know -- I've never looked at developing for the PS3 yet.

Even if you aren't going to target only Microsoft plattforms, the smart thing to do is usually to use DirectX too. You see, since it gives you 2 (well, nowadays the number grew to 4 thanks to Windows RT and Windows Phone 8) for free, you can just swap out the DirectX component for the system-specific component you need (Which most likely was designed to be similar to DirectX since its for all intents and purposes the industry standard), which you will have to do anyways if you are supporting something other than a normal PC. If you want to distribute on multiple platforms (not just multiple OS) is only logical to actually avoid OpenGL.

The PS3 doesn't actually implement the full standard if memory serves me well... it is based on, but not fully compliant with it (Which is just another pain in the ass that you get whenever you choose open standards or open source in general).

[TheMatrix]

It doesn't. Current version of OpenGL is, at best, as easy to program as DirectX 9, but much less flexible than said version of DirectX. Now, which version of DX are we on right now? I'll let you do the math.
Like I said, there's a trade-off.

There is nothing that should be hardware specific in DirectX or OpenGL. That's the whole point of having a HAL (Hardware Abstraction Layer). Thats why you see most devs using DirectX and almost nobody using OpenGL (at most, some do it as a -pretty much useless- option).
Okay, fine. I put the wrong word -- I meant system-specific.
DirectX is not a bad library, in fact, if I ever needed to, I might use it.

Even if you aren't going to target only Microsoft plattforms, the smart thing to do is usually to use DirectX too. You see, since it gives you 2 (well, nowadays the number grew to 4 thanks to Windows RT and Windows Phone 8) for free, you can just swap out the DirectX component for the system-specific component you need (Which most likely was designed to be similar to DirectX since its for all intents and purposes the industry standard), which you will have to do anyways if you are supporting something other than a normal PC.
I know that.

If you want to distribute on multiple platforms (not just multiple OS) is only logical to actually avoid OpenGL.
That actually depends on whether or not Microsoft will release an implementation for that platform. I know there isn't one for GNU/Linux(and there probably will never be), so one must use OpenGL.
There's nothing wrong with that, it's just another way of doing things.

The PS3 doesn't actually implement the full standard if memory serves me well... it is based on, but not fully compliant with it (Which is just another pain in the ass that you get whenever you choose open standards or open source in general).
Which, OpenGL ES or DirectX?

Anyways, the most important thing about including DirectX-specifics anywhere else than the backend effectively locks you into only Microsoft-approved platforms.
If you don't ever need to do anything else, than okay, fine. I can't think of any situations right now where you would need to use any driver-specific code that a game engine doesn't provide.

But look where we went: from Steam to graphics drivers and such. Perhaps we should get on topic? Continue in the other thread if you want.