Originally posted by Dragonlord
View Post
Announcement
Collapse
No announcement yet.
Steam Client For Linux Confirmed
Collapse
X
-
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.
Comment
-
Originally posted by Dragonlord View Post"Good"?
Originally posted by Dragonlord View Post"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
Originally posted by Dragonlord View Post"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 )
Originally posted by Dragonlord View PostSteam should do one thing and ONLY this: content delivery. All the rest should be none of their business.
Originally posted by xav1rSeveral steam games have Securom like their retail flavors. So you get 2 DRMs for the price of 1.
Comment
-
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.
Comment
-
Originally posted by hobbs27 View PostInterestingly, if run under Wine, only the opengl32.dll library is loaded.
Comment
-
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
Comment
-
Originally posted by Dragonlord View PostNope. 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
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.
Comment
-
Originally posted by Dragonlord View PostI 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?
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.
Comment
Comment