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 >>>> >>>> >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> http://list.valvesoftware.com/mailman/listinfo/hlcoders >>> >>> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
