This also adds a rather odd burden here, that allows Linux to get a better standing for gaming.
It is not that unknown that without mixing, Linux generally does not require anywhere near as much over head to run as windows. The minimum requirements to run a GUI on Linux is about 256MiB of RAM. This even includes GUIs like KDE and Gnome. Though XFCE and LXCE would be better if you really did only have 256MiB of RAM (well if you were using a DE... and not a slimmed down WM with only a few programs loaded into it) You can do just fine win 1GiB of RAM. Linux also, as an OS can run on some old Intel boards--that running an OS on would other wise be insane today. a Pentium 1 can still get (some) use with Linux. Not enough to really be noteworthy as a desktop PC... but, this is a lot less than the least you will get Windows 7 onto. So we have a nice toss up here: 1: Linux requires Software Rendering in place. IE: how rendering was done, before we got silly things like TNT and Voodoo on the market. 2: Linux requires significantly less overhead to run, as far as OS goes. If we can get it so that we can show Steam running on Linux, using mostly Software Rendering, and getting it to run as fast as the same game on Windows, on comparable hardware... This will definitely sell Linux as an OS... Which in turn will get various Graphics Card makers on board to add their support. You know--I kind of want to see somebody work on that goal then. I am almost ready to dig up some old books that go over the theory of 3d programming, just to pull make a software rendering engine for this idea. On Monday, June 14, 2010 07:59:45 pm Darren VanBuren wrote: > Yes, 3D drivers are definitely quite lacking on the GNU/Linux front, > but if Valve shows support for the development of these drivers, this > may prompt certain GPU manufacturers to step up their GNU/Linux driver > development. > > Darren L. VanBuren > ===================== > http://theoks.net/ > On Mon, Jun 14, 2010 at 18:35, Bob Somers <magicbob...@gmail.com> wrote: > > Something to consider, though, is that the 3D driver support is years > > behind from *ahem* a particular GPU manufacturer. I won't embarrass > > them by saying their name, so I'll just say their initials: ATI. > > > > Their driver support for Linux is, frankly, pathetic at best. The > > Fedora team is trying to solve this with their new free drivers in > > Fedora 13 (which, I'll admit, are quite good), but it's still not up > > to par with what you need to run a game. For example, the new free > > drivers have very little (read: practically none) support for basic > > vertex and fragment shaders. It will be at least another year before > > the free drivers are up to what ATI's crappy proprietary drivers are > > now. Even worse, right now you can get the proprietary drivers running > > on Fedora 11 alright, sort-of on Fedora 12 with some ugly hackery, and > > not at all on Fedora 13. Literally, ATI's Linux drivers are at least > > 12 months behind, and the free ones are 12 months behind that. > > > > Unless somebody gives ATI a swift kick in the nuts the situation does > > not look good. > > > > --Bob > > > > > > > > > > > > On Mon, Jun 14, 2010 at 5:01 PM, Darren VanBuren <onekop...@gmail.com> wrote: > >> Spoiler Alert. It's like the ratman drawing that says "She's watching > >> you." Canonical is she in that case. > >> > >> I'm personally a fan of Fedora, but if Steam on GNU/Linux is > >> distributed as a tarball, that'd be best in the interests of Valve. > >> Even if some people (mainly Ubuntu users) would be a bit stuck on the > >> concept of a tarball, it'd be minimal work for Valve, and maximum > >> cross-distribution compatibility. > >> > >> Darren L. VanBuren > >> ===================== > >> http://theoks.net/ > >> > >> > >> > >> On Mon, Jun 14, 2010 at 16:49, Harry Jeffery > >> <harry101jeff...@googlemail.com> wrote: > >>> It's all down to personal opinion, as long as it does what you need > >>> quickly and effectively then it's fine. I've yet to see the dark side > >>> in cannonical so I honestly can't say much about their ethics. > >>> > >>> Either way, I <3 Linux and so should Valve. > >>> > >>> On 15 June 2010 00:19, Katrina Payne <fullmetalhar...@nimhlabs.com> wrote: > >>>> Well a few points: > >>>> > >>>> The commands in the Linux Commandline... and well those on any UNIX or UNIX > >>>> Workalike have not really changed since the 1970s. You could pick up a book on > >>>> BASH or TCSH from the 1970s, and still have most of what you should do. > >>>> > >>>> This kind of has allowed for tools to be put around these base functions, such > >>>> as autocomplete, history and well--quite a few other really handy tools, to be > >>>> added into the Linux CLI, to make its functionality go above and beyond > >>>> anything cmd.exe is capable of. > >>>> > >>>> I still have yet to look into Microsoft's PowerShell though. > >>>> > >>>> This is why most Linux users use the CLI. It has developed into an experience > >>>> that is completely unlike the root canal that is cmd.exe. You can actually go > >>>> in, and get some functionality from it. A lot of functionality too. It also > >>>> gives the feeling that the user has more direct control--without that Pesky > >>>> GUI in the way (though, technically, this just has a bunch of other items > >>>> typically in the way, such as init.d, bash, various bash extensions-- maybe > >>>> screen... you are just trading one thing in the way, that is, a GUI, for > >>>> another thing, that is a CLI). > >>>> > >>>> Now, that said--there are plenty of Desktop Environments ('DE') that Linux can > >>>> make use of, that pretty much make requirement of CLI use unnecessary. That > >>>> is, between KDE4, LXDE, XFCE, E17 and GNOME2/GTK, the average Linux user > >>>> nearly never has to do anything on the CLI. Unless something has gone horribly > >>>> wrong. In which case, he should be able to get the local Linux Admin to fix it. > >>>> > >>>> As that technically is what he'd do if something went horribly wrong on > >>>> Windows. He'd get his local Windows Expert to fix it. > >>>> > >>>> The "required" use of the CLI rather than GUI to properly use Linux, is much > >>>> like how using Vi is "required" rather than EMACS for the proper use of Linux. > >>>> > >>>> Also, I use Fedora, and typically find it a LOT easier to work with than > >>>> Ubuntu. This maybe, because Fedora tries not to be a bunch of asshats to the > >>>> people upstream. The same cannot be said about Canonical, the owners of > >>>> Ubuntu. Where, from what I have seen on their policies by past actions... > >>>> their MAIN desire is to be asshats to the upstream. > >>>> > >>>> I have a long winded rant on why I do not like Ubuntu... I mostly just state > >>>> that nobody uses Ubuntu Linux. Typically most people go over to another Linux > >>>> Distro afterwards, generally agreeing that no matter what Linux Distro they go > >>>> to, be it Fedora, Puppy (well, prior to being based on Ubuntu), Arch, Slack, > >>>> Gentoo, Knoppix, CentOS, LFS, etc., is better than Ubuntu... either that, or > >>>> they return to Windows--only using Ubuntu as a rescue disk setup. > >>>> > >>>> Right, now then. Back to your regular discussion > >>>> > >>>> ~Katrina > >>>> > >>>> On Sunday, June 13, 2010 07:20:08 am Harry Jeffery wrote: > >>>>> People like the command line because it's very fast to do what you > >>>>> want if you know what you are doing. So far ubuntu seems to be the > >>>>> most user friendly linux distro and what a majority of linux gamers > >>>>> might use. > >>>>> > >>>>> Personally I'd just use arch-linux and optimize my system...a lot. As > >>>>> long as nVidia release decent linux drivers it's all good. > >>>>> > >>>>> On 13 June 2010 14:01, Adam Buckland <adamjbuckl...@gmail.com> wrote: > >>>>> > A couple of things: > >>>>> > > >>>>> > Elan Ruskin gave a good talk on porting to consoles at GDC08. The > >>>>> > slides are on Valve's website. There's something in there that may > >>>>> > help you here: > >>>>> > > >>>>> > #ifdef __GNUC__ > >>>>> > #define MAXSI_THREADED_VARIABLE __thread > >>>>> > #else > >>>>> > #define MAXSI_THREADED_VARIABLE __declspec( thread ) > >>>>> > #endif > >>>>> > > >>>>> > You may wish to use another define for windows rather than an else > >>>>> > statement in case you wish to port it somewhere else in the future. > >>>>> > > >>>>> > Also I agree, the Mac and Linux ports are incredibly similar. In fact, > >>>>> > on the Mac port a shell script is executed first to determine whether > >>>>> > it's running on OS X or Linux. > >>>>> > > >>>>> > Finally Linux could be a great consumer platform. Before it can become > >>>>> > this, it needs to learn that not everyone is a power user, and make > >>>>> > things simple. Learn from the Mac app bundles, and remove reliance on > >>>>> > the command line (for example the output is shown on the update > >>>>> > software). It scares normal users. That, and a lot of power users > >>>>> > (like myself), don't want to have to rely on the command line for > >>>>> > everything. > >>>>> > > >>>>> > On 13 June 2010 13:28, Jonas 'Sortie' Termansen <hlcod...@maxsi.dk> wrote: > >>>>> >> I'd like to share a few experiences about porting code and writing > >>>>> >> portable code. Scroll down, if you just want my thoughts on how portable > >>>>> >> the Source Engine is. > >>>>> >> > >>>>> >> Recently I've been porting my in-development digital distribution > >>>>> >> platform to GNU/Linux for the fun of it. Naturally, most of my code > >>>>> >> didn't work right out of the box. But it is worth that several > >>>>> >> subsystems actually worked at the first attempt, or with an edit or two. > >>>>> >> For instance, my string system and parser classes/functions compiled > >>>>> >> right away. > >>>>> >> > >>>>> >> However, stuff like accessing the filesystem, multithreading, user > >>>>> >> interfaces, networking, and so on didn't work because it relied on the > >>>>> >> Windows API. The interesting part here is that POSIX does things > >>>>> >> differently; but almost in the same manner as Windows. That means for > >>>>> >> each Windows API call you use, there is often one or more POSIX calls > >>>>> >> that does the same thing (if you add a little abstraction, that is). > >>>>> >> > >>>>> >> Now, some of you heavily suggested the use of #ifdefs all around the > >>>>> >> code. You should not use #ifdefs each time you rely on platform specific > >>>>> >> behavior, but only in shared function calls or in headers. For instance, > >>>>> >> if you have to open a file. On Windows you can call the CreateFile > >>>>> >> function, while POSIX supports the open function. That means for each > >>>>> >> file opening, you need to write something like. > >>>>> >> > >>>>> >> #ifdef linux > >>>>> >> int FileHandle = open(Path, Flags); > >>>>> >> #elif defined(WIN32) > >>>>> >> HANDLE FileName = CreateFile(...) > >>>>> >> #endif > >>>>> >> > >>>>> >> Naturally, this isn't very pretty. And if this was used all over the > >>>>> >> Source Engine you would spend a lot of time writing #ifdefs and checking > >>>>> >> platform specific documentation. However, I am not saying #ifdefs are a > >>>>> >> bad idea. But instead of using them all over your code, you should move > >>>>> >> them to a shared class or function that simply implements all this once. > >>>>> >> In my code, I declared an abstract baseclass called MaxsiFileSystem that > >>>>> >> implements all the common functions to access the local filesystem. So > >>>>> >> now when I wish to open a file for reading, I would call: > >>>>> >> > >>>>> >> MaxsiHandle FileHandle = FileSystem()->OpenFile(Path, MAXSI_FILE_READ | > >>>>> >> MAXSI_FILE_SEQUENTIAL); > >>>>> >> > >>>>> >> This additional layer of abstraction makes it very easy to add support > >>>>> >> for new platforms as you just have to define a new child of the abstract > >>>>> >> baseclass. I have also added such a layer for my Window System. This > >>>>> >> means I call my own APIs in my actual code, and then it redirects it to > >>>>> >> the Windows API or GTK+ depending on your platform. > >>>>> >> > >>>>> >> You might also have noticed I implemented a FileSystem() function, in > >>>>> >> the same manner I have implemented a WindowSystem() function that > >>>>> >> returns the window system in use by the current function/class. This > >>>>> >> makes it easy to simply swap the window system on the fly. For instance, > >>>>> >> my source mod links against my distribution platform (LGPL) and my mod > >>>>> >> then implements some of these interfaces. It could implement the > >>>>> >> MaxsiWindowSystem class using VGUI and then my programs could be > >>>>> >> natively drawn ingame with mininal work. > >>>>> >> > >>>>> >> Other porting issues includes how the VS compiler breaks a lot of the > >>>>> >> C99 standard. To counter this, I have simply declared a lot of macros in > >>>>> >> my header files that replaces platform specific behavior. #defines > >>>>> >> are > >>>>> >> very powerful for this. For example, to declare a thread-specific > >>>>> >> variable, I would use this header define: > >>>>> >> > >>>>> >> #ifdef __GNUC__ > >>>>> >> #define MAXSI_THREADED_VARIABLE __thread > >>>>> >> #else > >>>>> >> #define MAXSI_THREADED_VARIABLE __declspec( thread ) > >>>>> >> #endif > >>>>> >> > >>>>> >> And then use the MAXSI_THREADED_VARIABLE macro to declare each threaded > >>>>> >> variable. My experience is also that the GNU Compilers throw much more > >>>>> >> errors and warnings than the Visual Studio compiler - and it is often > >>>>> >> right to do so. Visual Studio teaches you to write bad > >>>>> >> standards-breaking code, even if you just compile using MinGW you will > >>>>> >> get to fix a lot of issues that makes your code rather non-portable. > >>>>> >> (Like avoiding Microsoft-specific extensions to the C Library, in some > >>>>> >> cases.) But Microsoft did break the standard enough that you might need > >>>>> >> to use some of the above methods for porting, just to get your code > >>>>> >> compiling using MinGW. > >>>>> >> > >>>>> >> > >>>>> >> Now to return to the Source Engine. In my experience a lot of stuff in > >>>>> >> the SDK code is already defined using interfaces, classes, and such. > >>>>> >> That means the actual porting issues have been outsourced to the Engine. > >>>>> >> This, in turn, means that the SDK code will be rather easy to port > >>>>> >> compared to the Engine. Fortunately, as the Source Engine already is > >>>>> >> highly modular using interfaces, it is easy to just swap a DX renderer > >>>>> >> with OpenGL. As such, they already have the framework to make their code > >>>>> >> work on new platforms - all they have to do is implement their > >>>>> >> interfaces using the local system calls. If you start to do this on the > >>>>> >> low-level interfaces and move upward, then soon your program starts > >>>>> >> working in all its glory. > >>>>> >> > >>>>> >> As for a Steam Client for GNU/Linux. It exists. I lost the link, but it > >>>>> >> seems that Valve uploads nightly builds of their Steam Client, and each > >>>>> >> day it works just a bit better. Last I heard, the Steam Client actually > >>>>> >> logged on and the actual UI was partially drawn. I am not sure why Valve > >>>>> >> is so silent about this - perhaps it's just experimental, or they they > >>>>> >> to make a big deal about it, like they did with the Mac. Seriously, when > >>>>> >> are they gonna shut up about it? Last I saw was that they made a funny > >>>>> >> TF2 comic about it. > >>>>> >> > >>>>> >> > >>>>> >> Porting programs to Linux hasn't been very hard for me, though it is a > >>>>> >> lot of work, if you want to do it properly. It seems that the Source > >>>>> >> Engine is already highly portable and GNU/Linux build doesn't seem too > >>>>> >> difficult, as it seems from the nightly builds. There is no doubt about > >>>>> >> whether we need a client for GNU/Linux, it is just a matter of time > >>>>> >> before they announce and release it. > >>>> > >>>>> > Bucky _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
