Steam Client For Linux Confirmed

[xav1r]

"Good"?

"it doesn't just take from the user" => It locks down the game files so you have no more free access to them ( including various "steam problems" which forced me to install the game from an official release instead since it messed up directory locations )

"gives you auto-updates" => Which constantly break your games if you (a) mod with them or (b) are no more maintained actively

"community features" => Heaps of dead steam groups and in general a placed filled with attention whoring facebook crook-heads? Now that I call an "achievement" ( end sarcasm )

There's more shit to it so the list could go on. Steam should do one thing and ONLY this: content delivery. All the rest should be none of their business.

Very well said. That's why for online delivery i usually tend to recommend GoG.com or probably stardock's system, although in much less degree.

[Thetargos]

IMO the problem with Steam was Valve becoming a publisher... Which means all sorts of DRM crap. Annoying as it is, there is no other platform (well maybe except iTunes) that has achieved the same degree of success at content delivery. It is very unlikely that they're gonna drop DRM, but at least the system is somewhat transparent (unlike SecuROM). In the end we all know that legit users are the ones who actually get scrwed with all the DRM crap, and pirating goes on rampant (even on consoles).

Steam with all of its problems, has also helped resolve many inherent gaming problems. For the longest time I despised it, and still I do not trust it completely (even when in the end I ended up giving in and opening an account), I've only known of very few cases of total lock-down with Steam and account banning on no justified grounds. Steam does have a great power within itself, though: By being a means of game delivery, it could also become the most powerful and biggest publisher if they went multiplatform.

[Aradreth]

"Good"?

I never said it was "good", just better then secuROM.

"it doesn't just take from the user" => It locks down the game files so you have no more free access to them ( including various "steam problems" which forced me to install the game from an official release instead since it messed up directory locations )

"gives you auto-updates" => Which constantly break your games if you (a) mod with them or (b) are no more maintained actively

When I've used steam I've never had these problems and this is the first I've heard of them. As for the locked down game files, I don't actually care I rarely touch them anyway.

"community features" => Heaps of dead steam groups and in general a placed filled with attention whoring facebook crook-heads? Now that I call an "achievement" ( end sarcasm )

Never used them but I'm not suprised that it's filled with idiots. Every main stream site fills up with idiots in no time, you can't really blame valve for that.

Steam should do one thing and ONLY this: content delivery. All the rest should be none of their business.

That's your opinion and I've sure there are many people who would disagree with it. I don't have much of an opinion on that matter since boxed version >> digital download version in my eyes.

Several steam games have Securom like their retail flavors. So you get 2 DRMs for the price of 1.

They don't want you to miss out on the fun because they are nice like that.

[hobbs27]

Valve and Linux

1. The listed libraries are very likely to be server libraries. The L4D demo was shipping with a server, which was invoked locally when the client couldn't establish a connection to a 'valve gaming' server in the multiplayer demo. I guess the Linux and the Windows server share most of the source tree and some of the Linux libraries were included by accident

2. Regarding the job advertisement for a Software Engineer, again it is likely to be mainly on the server side. Valve is certainly keen on Linux on the server side. Their new Steam Cloud server farm is very likely to be implemented on Linux judging by the job advert requirements. It certainly would be a great compliment to Linux that a former MS employee is choosing Linux to run their application servers.

3. It has indeed been confirmed that Postal 3 will be released for Linux and the Mac http://www.omgpcgames.com/content/view/45/37/ and it uses Vavle?s Source Engine. It is thus certain that a Source-based game will be available for Linux in 2009. The question is whether ?Running With Scissors? are doing this ?port? on their own back or whether indeed Valve is providing an OpenGL/Unix/SDL interface for their Source Engine. Certainly, the latter case would be more efficient as many more games could benefit from this additional interface. The predecessor (GoldSrc Engine http://en.wikipedia.org/wiki/GoldSrc) already had an OpenGL render interface.
Maybe ?Running with Scissors? are contributing to the development of the OpenGL interface and thus got a special deal? They said they do a lot of custom coding. We will certainly find out in 2009.

4. OpenGL headers are included in the Source SDK but this might be some remains from the old GoldSrc Engine? I have noticed that the steam overlay interface is loading OpenGL and DirectX libraries. I found this info in the GameOverlayRenderer.dll.log file.

Sat Nov 29 15:10:11 2008 UTC - Game is using opengl32.dll... hooking.
Sat Nov 29 15:10:11 2008 UTC - Game is using D3D9, preparing to hook.
Sat Nov 29 15:10:11 2008 UTC - hookDirect3DCreate9 called

Interestingly, if run under Wine, only the opengl32.dll library is loaded.

[Yfrwlf]

Interestingly, if run under Wine, only the opengl32.dll library is loaded.

Will be interesting to see competition heat up further between DX and OGL once Gallium3D DX/OGL drivers are adopted in Linux, though perhaps these APIs won't be needed once GPU/CPUs are fully programmable?

[Dragonlord]

Nope. The APIs are still required since you shaders only can deal with polygons you send... but the sending itself requires a specific API. And the APIs of course also come ( as could it otherwise be in the world of informatics ) with different and by itself incompatible shader languages. Lucky is who has an abstraction layer in between :P

[Svartalf]

Nope. The APIs are still required since you shaders only can deal with polygons you send... but the sending itself requires a specific API. And the APIs of course also come ( as could it otherwise be in the world of informatics ) with different and by itself incompatible shader languages. Lucky is who has an abstraction layer in between :P

Actually, internally, they're like massively parallel stream processors.

Some are dedicated to doing vertex processing.
Some are dedicated to doing shading.

With DX10 or GL 2.1/3.X capable cards, there's not even a specific dedication to portions of the pipeline. It can morph from one demand set to the next or be GPGPU entirely. The whole lot is driven by driver software that transforms the given graphics API into stream processor instructions.

This is why Gallium3D's so cool. It, in theory, can produce nearly optimized instruction mixes for a given OpenGL (Or D3D...ugh...) api call set- and do it for CPUs, GPUs or a mix thereof via LLVM.

[Dragonlord]

I guess the stress here is on "in theory"? Haven't looked at Gallium3D at all yet but would supporting all kinds of graphic card intermediate APIs ( aka hardware interface not software interface ) not be quite an undertaking?

[Svartalf]

I guess the stress here is on "in theory"? Haven't looked at Gallium3D at all yet but would supporting all kinds of graphic card intermediate APIs ( aka hardware interface not software interface ) not be quite an undertaking?

GCC manages:

Fortran
C
C++
Pascal
Object Pascal
Java

It's little different with GPU stuff, and actually the API's underneath are very, very similar. Fact of the matter is, AMD's drivers are intrinsically identical past the API edge. Ditto NVidia. All Gallium3D brings to the table is the same framework for FOSS drivers and brings the bulk of the performance mojo via a JIT that can handle all sorts of things. It's a bit different in that only recently did the GPU vendors add efficient CPU shader support into their drivers and it's a bolt-on that they did to cope with shader modalities that aren't supported on a given GPU (See: IGPs pre DX10- they typically rely on the CPU to inefficiently do Vertex operations...). In the case of Gallium, you've got interchangeable processing backends that can target a given GPU's instruction set or a given CPU's without it being a bolt-on.

[murak]

Be still my heart...