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