My university uses those in internet terminal kiosks placed in prominent public areas (like student lounges). A recent emergency (dead laptop battery) forced me to use one of those. God, was it painful.
I don't doubt that Valve has investigated the possibility of a native Linux client. However, Phoronix doesn't seem to be looking in the right places. Let's go through what they brought up from the perspective of someone who is familiar with the Source engine:
steamclient_linux.so - this is the ONLY interesting file. I have a sneaking suspicion, though, that a majority is stubbed out and this is a remnant of the port of L4D to Steamworks - it uses a more generic library layout to work with any application, not tightly integrated with Source as before. Perhaps the server uses some functions in it to connect to the Steam master servers. That would explain why they only found it to be about half the size of the Windows version.
studiorender_i486.so - Valve calls their 3D model format a "studio model." I'm fairly certain that this file is stubbed out and only the model loader is available - the physics engine needs it to get at mesh data.
vstdlib_i486.so - Valve's standard libraries. Routines and classes used throughout the engine. No surprise, it's been shipping as long as the dedicated server has.
libsteam_api_linux.so - The API into Steam. Again, probably a Steamworks artifact. Again, perhaps part is used by the dedicated server.
engine_i486.so - core engine functionality. Anything that isn't factored out into another library (there are about 45) exists in here. I'm fairly sure that typically, left4dead.exe connects to Steam, then loads this library to make stuff happen. Core client and server code (operation, not logic) is in here.
Unfortunately, I have since removed the demo from my computer (bought the actual game, well worth it) and can't investigate these files any further. I don't think this is 100% indicative of Valve having a Linux client ready, but rather extreme extrapolation on Phoronix's part. I'm completely with them on wanting a client though.
X11R6.7: April 2004
OS X 10.4: April 2005
OS X 10.5: October 2007
Not to mention that Apple puts a large amount of effort into customizing X to their needs. Oh and there's also the little niggle that X is just another application that a very small niche of Mac users need...
The whole point of XNA is that games can run on the Xbox and Windows with (virtually) no modifications to the source code. Your own desktop PC will make a pretty good VM.
I thought as long as (say) Nvidia kept provided drivers, and software kept querying for the hardware's capabilities, DirectX & OpenGL were pretty much on a par with each other....
That's the entire problem. nVidia would have functionality available in both DX and GL drivers on release day and would frequently submit it to the ARB for ratification as an extension, which often would become a core feature in the future.
Unfortunately, nobody else took their lead. In good scenarios, you'd have separate implementations on different hardware - extensions named GL_NV_blah and GL_ATI_blah. Sometimes only one would implement it (I think ATI's vertex buffers were judged superior and promoted to core shortly thereafter).
The worse offender, though, (and really the sign that OpenGL was going nowhere) was the geometry shaders. nVidia had the supporting hardware first, but rather than make it an extension specific to their drivers, they implemented it and submitted it as a GL_EXT extension - one that everyone should implement. Nobody else did.
With all the talk of running one's own OpenID provider, why not run it on your own machine behind a DynDNS or similar provider and use PAM to authenticate against/etc/shadow?
Some have said that Wine DLLs run on Windows. This is to be expected.
Now given that you are in the process of implementing Direct3D 10, do you think it could be a solution to the mess that is Microsoft's insistence that D3D10 only run on Vista? Would it be feasible that users could take the Wine DLLs, install them on their XP system, and get around the OS upgrade?
Slashdot Mirror
disregard above post.
base64 decoding gives a bzipped tarball, decompress with your favorite utility.
HOWEVER, it it obviously windows-specific, uses the win32 API to install itself and - I think - replicate the storm code in-place.
I think it's bzipped, I'm not on a machine with file(1) available to test.
oh how i wish i had mod points...
My university uses those in internet terminal kiosks placed in prominent public areas (like student lounges). A recent emergency (dead laptop battery) forced me to use one of those. God, was it painful.
Dearest Psion,
Netbook. Netbook netbook netbook. Netbook netbook netbook, netbook netbook!
Netbook,
Netbook.
- Netbook
I'm typing this from OS X Lepoard on my 12" PowerBook G4.
Someone tell me that parent is not serious.
I don't doubt that Valve has investigated the possibility of a native Linux client. However, Phoronix doesn't seem to be looking in the right places. Let's go through what they brought up from the perspective of someone who is familiar with the Source engine:
steamclient_linux.so - this is the ONLY interesting file. I have a sneaking suspicion, though, that a majority is stubbed out and this is a remnant of the port of L4D to Steamworks - it uses a more generic library layout to work with any application, not tightly integrated with Source as before. Perhaps the server uses some functions in it to connect to the Steam master servers. That would explain why they only found it to be about half the size of the Windows version.
studiorender_i486.so - Valve calls their 3D model format a "studio model." I'm fairly certain that this file is stubbed out and only the model loader is available - the physics engine needs it to get at mesh data.
vstdlib_i486.so - Valve's standard libraries. Routines and classes used throughout the engine. No surprise, it's been shipping as long as the dedicated server has.
libsteam_api_linux.so - The API into Steam. Again, probably a Steamworks artifact. Again, perhaps part is used by the dedicated server.
engine_i486.so - core engine functionality. Anything that isn't factored out into another library (there are about 45) exists in here. I'm fairly sure that typically, left4dead.exe connects to Steam, then loads this library to make stuff happen. Core client and server code (operation, not logic) is in here.
Unfortunately, I have since removed the demo from my computer (bought the actual game, well worth it) and can't investigate these files any further. I don't think this is 100% indicative of Valve having a Linux client ready, but rather extreme extrapolation on Phoronix's part. I'm completely with them on wanting a client though.
X11R6.7: April 2004
OS X 10.4: April 2005
OS X 10.5: October 2007
Not to mention that Apple puts a large amount of effort into customizing X to their needs. Oh and there's also the little niggle that X is just another application that a very small niche of Mac users need...
The whole point of XNA is that games can run on the Xbox and Windows with (virtually) no modifications to the source code. Your own desktop PC will make a pretty good VM.
Apple doesn't use X. They probably didn't have time to fix WindowServer before launch, but I'd imagine that it will be fixed for Snow Leopard.
Photosynthesis?
BitTorrent.
Only on Slashdot will a joke about Lego Mindstorms be considered insightful.
Interesting. Here in Connecticut you're required to declare impartiality.
JPEG compression.
Probably not, ATI had supporting hardware several months later. nVidia was only first to market, nothing more.
There's a couple of ext3 drivers for Windows (one open-source, one not) that also work pretty well, so you can go both ways.
That's the entire problem. nVidia would have functionality available in both DX and GL drivers on release day and would frequently submit it to the ARB for ratification as an extension, which often would become a core feature in the future.
Unfortunately, nobody else took their lead. In good scenarios, you'd have separate implementations on different hardware - extensions named GL_NV_blah and GL_ATI_blah. Sometimes only one would implement it (I think ATI's vertex buffers were judged superior and promoted to core shortly thereafter).
The worse offender, though, (and really the sign that OpenGL was going nowhere) was the geometry shaders. nVidia had the supporting hardware first, but rather than make it an extension specific to their drivers, they implemented it and submitted it as a GL_EXT extension - one that everyone should implement. Nobody else did.
Creating micro black holes at the LHC is also a theory, and highly speculative at that.
When the article says chipset, they mean the nForce, not the GeForce.
Portal.
Come to think of it, with Half-Life already being mentioned in this thread, Valve really does have a monopoly on GOOD game design.
With all the talk of running one's own OpenID provider, why not run it on your own machine behind a DynDNS or similar provider and use PAM to authenticate against /etc/shadow?
Some have said that Wine DLLs run on Windows. This is to be expected.
Now given that you are in the process of implementing Direct3D 10, do you think it could be a solution to the mess that is Microsoft's insistence that D3D10 only run on Vista? Would it be feasible that users could take the Wine DLLs, install them on their XP system, and get around the OS upgrade?