Linux as a Gaming Platform

This past week, I've gotten more and more Windows-native games (as well as *nix ports) to run on my Arch x86_64 box. I originally built the computer with gaming in mind, but with Windows 7 getting worse and worse by the minute, booting into Windows just to play a game was becoming a more and more laborious task, not to mention that dirty feeling you get when you boot a computer and the Windows logo pops up.

I had originally used the latest stable version of Wine (1.0.1) obtained from Arch's User Repository, but found it was just as buggy as my previous Wine experiences. I managed to get Halo to run as mentioned in a previous post, however there were still relatively minor issues that persisted, such as the odd screen flicker, graphical problems on screen panning, and an odd box of discoloration that appeared in the top-right corner of the screen.

On a whim I decided to upgrade to the latest developmental version of wine (1.4.1), which was also in the AUR, though the PKGBUILD required some minor editing as wget was met with a 404 error trying to download the necessary files from the link given in the PKGBUILD. Luckily a fellow Archer posted a revised PKGBUILD in the comments, and it worked like a charm. Once the new Wine was up and running, I double-checked Halo to make sure the upgrade didn't brick it... Far from, it increased performance ten-fold, which is hard for me to say because it really wasn't bad at all to begin with. Suffice to say an immediate performance increase was more than noticeable.

After perusing the Wine AppDB for games I owned that were known to work well with Wine, I decided I'd give Half-Life 2 and Counter-Strike: Source a go. I encountered, and eventually fixed the same problem in both games. They would both load, but neither rendered any sound. After a quick trip through 'winecfg' I set the sound to OSS instead of ALSA, and it now works wonderfully. Not quite sure why, since ALSA is recommended explicitly over OSS for Wine, but with ALSA I can only play Halo, and with OSS all three games work. I suspect it has something to do with Steam, but I'll leave well-enough alone for now.

Now for the less-troublesome ports. There are countless remakes of the original DOS doom, most adding additional functionalities such as the ability to jump/crouch or have crosshairs, et cetera. Chocolate-Doom (AUR, detecting a trend here?) is a play on 'Vanilla Doom', as in the untouched original DOS version. It is as close to the original as possible, and preserves only original functionalities, as well as the original bugs. Using chocolate-doom I was able to play Doom 1, Doom 2, TNT, and Plutonia, just by setting the -iwad option on the command line and the path to the wad. Now I bought the id Super Pack on Steam some time ago, so I have access to the WADS on my Windows partition. Of course starting the game via a rather long terminal command isn't exactly efficient, so I wound up toying around with my ~/.bashrc file and got a rather satisfactory result.

~/.bashrc is used to create 'Aliases' for commands entered into the shell, using a very simple configuration file. Here's the portion of my ~/.bashrc pertaining to chocolate-doom:

alias chocolate-doom1="chocolate-doom -iwad ~/Data/DOOM.WAD"
alias chocolate-doom2="chocolate-doom -iwad ~/Data/DOOM2.WAD"
alias chocolate-doom-plutonia="chocolate-doom -iwad ~/Data/PLUTONIA.WAD"
alias chocolate-doom-tnt="chocolate-doom -iwad ~/Data/TNT.WAD"

Now instead of using the -iwad argument and specifying the full file path, I can just append a bit to the end of the command, so 'chocolate-doom1' will launch chocolate-doom using the DOOM.WAD. Much more efficient.

Getting away from the first person shooter category for a bit, Astromenace(AUR) is an extremely addictive space-scrolling 3D spaceship shooter, that is open-source. It also features RPG elements, as you buy a spaceship (from a rather large selection), and set about custom-configuring it with various hardware components such as shields, power-sources, engines, and of course weaponry. You earn money at the end of each level, which you can spend on these things as well as hull-upgrades. The difficulty level is also very customizable, you aren't presented with a simple easy/medium/hard menu, you actually get to specify various game mechanics such as damage bonuses, armor bonuses, and the like. You can also speed up/slow down the game in play using the F5-F7 keys. It is extremely addictive, and took up a few days of my life, but it is by far the best native Linux game of its kind I have ever seen.

My only hesitation about Linux originally was having to sacrifice quality gaming time to gain all of Linux's other benefits, but thanks to an increase in the availability of native/ported games for Linux, and the truly fantastic work Wine's developers are doing, I may eventually be able to rid my HDD of that ugly NTFS partition for good.

1 TB Uploaded

At long last, after 260 Days and 15 hours of uptime, My torrent-dedi has seeded over 1 TB worth of data, compared to 393.76GB downloaded, leaving me with a share-ratio of 2.6:1.

The torrent-dedi runs on my Mint-Server box, which performs a consortium of other tasks as well such acting as a network share, webserver, print server, et cetera. Originally the old P4 box ran Mint 7, with a copy of Azureus obtained from Vuze's website, as the version in the repositories was several versions behind. Since then I've migrated that box to Mint 8, but copied over the Azureus install and the ~/.azureus folder as it kept track of statistics and other goodies.

So on this most auspicious of days, I present to you my top 5 most excessively seeded torrents:

Torrent	Size	Total Uploaded	Share Ratio
Backtrack 4 - Final	1.46GB	152.38GB	104.168:1
Ubuntu 9.10 Server i386	640.57MB	22.04GB	35.256:1
Arch Linux 2009.08-netinstall-x86_64	176.37MB	5.61GB	32.492:1
Debian 503 i386 CD 1	645.45MB	12.15GB	19.279:1
Backtrack 4 Pre-Final	1.29GB	10.25GB	7.897:1

Bittorrent is an incredibly inexpensive, and voraciously efficient means to transfer and share content and enables people to spread ideas on a 'peer-to-peer' level. It also enables people to help others. Yes, I'll say it again. Despite what the corporate giants want you to think, Bittorrent's primary use is not piracy, it is to share. Just like a steak knife itself is not inherently dangerous, unless you use it to stab someone instead of just using it to enjoy your meal like a normal person.

The ideologies of GNU, Linux, and Bittorrent all walk hand-in-hand, and with the way the world is today, I'd be less hesitant to trust actual people than I would a nameless, faceless corporation who supposedly has your best interests at heart, but won't let you violate the terms of your End User License Agreement to alter their defective product, and try to make it work (Here's your shoutout Microsoft).

Nearly all of the Linux distributions I use are licensed under the GNU GPL or similar and as such I am free to copy and distribute them as much as I please, in fact I am encouraged to do so. Therefore I prefer to download my distros via Bittorrent rather than http, because after they're done downloading, I can seed them and help other people get a copy of it and use Linux themselves. Bittorrent is in the truest sense of the word, a community of sharing. Sharing is not a bad thing, it is a good thing.

The climate in this field has turned so sour as of late that I've heard people use the word "download" as if it had a negative connotation associated with it. "Oh you shouldn't download things, it's wrong and you'll go to jail." Every time you visit a website, you are downloading the html/php/css files, as far as I know it's still legal to visit websites... for now. The focus has been taken off the content in question, and the gun of blame pointed at the community as a whole. You can't blame the protocol, that's like blaming arson on the gasoline rather than the arsonist. It's illogical, it's a gross and offensive misconception, and above all else, it is a staggering new level of asinine.

For your viewing pleasure:

Yet Another Reason to Avoid Windows

In my CS class today, the computer station at which I sit was infected with all sorts of nasty malware. When I attempted to load Firefox, the virus loaded a dummy version of the program, probably designed to steal user-inputted data such as login information for various sites. Same with Internet Explorer. I found and installed a portable version of clam4win, since I didn't have the necessary admin privileges to install the normal version, and let that scan the disk for a while until class was over and I had to leave.

It found several threats, but none of them were the malicious program in question. This is most likely the culprit, as the symptoms match those exhibited by that computer exactly. I found that link via google using my netbook (running Arch i686 w/ XFCE) since I tend to avoid using Windows computers for security reasons, and using a Windows box you know to be infected is just asking for problems.

It's a typical virus that plagues you with pop-ups informing you your computer has been infected and you should buy their product to rectify this situation. This is EXACTLY the type of situation that can be avoided by switching to an open-source operating system like Linux, that allows administrators to legally alter source-code to prevent these types of threats, not to mention that Linux isn't affected by Windows viruses which inherently makes it more secure since the vast majority of viruses target the Windows platform. It is inexcusable that while using a computer on my college's campus, you run the risk of being phished. This could all be avoided by using open-source software.

Notepad was also infected, so I found another text editor on the computer, and wrote a note to the IT dept. including all relevant info and the above link and left it up on the screen. Hopefully they will realize that running large numbers of Windows boxen using Symantec's woefully inefficient AV software on a network of college students is not the best idea. I also changed the desktop background to this to further emphasize my point. Here's hoping it doesn't fall on deaf ears.

Azureus/Pidgin Integration

That write-up I promised in the "A whole 'nother level of Geekdom' post regarding the implementation of Pidgin as a remote-content-addition-mechanism for Azureus is now done... If you've ever wanted to be able to tell your home torrent box to start downloading something by doing something as simple as sending an Instant Message, give it a glance.

Using Pidgin To Add To Your Azureus Queue Remotely

First things first, there are countless ways to control a torrent-box remotely that will offer you a higher level of control than this procedure, but if your looking for a quick and easy way to add content on-the-fly, without much setup, then this guide is for you.

Requirements:

• Azureus Vuze (latest version recommended)
• Pidgin (latest version recommended)

The goal of this little project is to be able to add torrents to Azureus' queue from any computer with an AIM client. The basic setup is this: Azureus has a feature where it will autoscan a directory for new content at a predetermined time interval (i.e. 60 seconds). Pidgin has a plug-in where it will autoaccept file transfers from pre-defined 'AIM buddies', and save them to a pre-defined directory. By daisy-chaining these two features, we can IM .torrent files to an AIM account running on Pidgin on the torrent box, at which point Pidgin will automatically accept the file transfer, and Azureus will subsequently add the torrent to its queue.

Setting up Pidgin

Create a NEW AIM account that will be used on the torrent-box, say something like Steves-torrent-dedi. Next you are going to want to download and install Pidgin onto the torrent computer. Now, I use Linux almost exclusively, so I downloaded pidgin through my distribution's repositories. However if you are using Windows you can get the installer from Pidgin's Site. Now to actually set up the account settings. When you launch pidgin it will prompt you to enter account information.

Click the Add button and fill out the fields accordingly with the information of the AIM account you just created. Pidgin can use many protocols besides AIM, such as Yahoo, ICQ, Jabber, Google Talk, et cetera, so you may be able to use accounts operating on those networks as well, though I haven't tested it myself. It's also probably a good idea to have it remember the account password so it can login automatically.

If after entering all the information, and verifying that you input it correctly, the account still won't log in, you may have to fine-tune some of the advanced settings. The two biggest problems are 'Use SSL' and 'Use Client Login'. Toy around with these, SSL usually needs to be turned off for Pidgin to login to an AIM account successfully.

By this point, you should have the AIM account running on Pidgin, now you need to add your own personal AIM account to the newly created account's buddy list. To add your personal account as a buddy, simply click Buddies>Add Buddy and fill out the form. Once you have done this go Tools>Plugins, and check off autoaccept.

Next click the configure plugin to fine-tune its settings. Blocking transfers from users not on your buddy list is probably a good idea, since ideally you would want you to be the only person capable of doing this. The pop-up is a personal choice. Creating a new directory for each user will save all the transfers from Buddy-A in /folder/Buddy-A/file, this is useful for other applications, but not this one since Azureus will only scan one directory for .torrent files, and it won't do it recursivley. Configure the folder where you want the uploaded torrent files saved, the simpler the better. Despite what the screenshot says I used "/home/mint/Uploads".

Now just right-click the Buddy you want to autoaccept files from, and click autoaccept. Then check autoaccept once again.

Setting up Azureus

Congratulations, your done configuring Pidgin, now onto Azureus. I use version 4.3.1.4 with the classic interface, so you may have to adjust this based on your individual settings. Find your way into the options menu (Ctrl key and , key) and select mode, then change it to advanced.

Now while still in the options menu, expand the "Files" submenu, then highlight "Torrents"(don't expand click the actual menu name). Now check off "Import new .torrents automatically", and enter the directory that pidgin will autosave to. You can also modify the scan interval if you so choose.

And Voila! The setup is done. Try sending some .torrent files to the account set up on the torrent box, from the account you enabled auto accepts from. This isn't the most powerful solution when it comes to remote management, but it is one of the easiest to set up, and so long as you're not doing anything too intensive, it should suit you fine.

Halo & Doom 3 on Linux

First things first, I'm officially converted; Arch is my new OS. It truly is infinitely customizable as you build it from the ground up, and I'm loving every minute of it. Anyway...

Gaming has long-been the one thing tying me to Windows. Yes there are Linux games, but let's face it: there's no Linux equivalent for some of the great Windows games out there, such as Half-Life, Halo, Call of Duty, et cetera. WINE is a possible solution, but to be honest I've never had much luck with it. I managed to get Dreamweaver running in it a few years back, but haven't touched it since then. Several days ago I figure I'd give it another go and try to get Halo CE (the first one) running.

Initially I tried it on my laptop, with an ATI Radeon 3200HD chipset, however the open-source Radeon drivers weren't getting along too well with it. The opening videos worked (I didn't need to pass the --novideo argument), but when the game loaded as far as the initial menu screen... Well I'm not sure how to describe it. Suffice it to say it was pretty recognizably a graphics issue rather than a WINE issue.

At this point I decided that rather than fiddle around with building Catalyst from AUR on a 64-bit machine, I'd try it out on my desktop, which has a more powerful Nvidia card (9600GT) anyway. That worked like a charm. The proprietary Nvidia drivers are fantastic, almost to the point where I forgive Nvidia for making them proprietary, but not quite. The game will load in a window or fullscreen (depending on your wine settings or command line arguments) and play damn-near flawlessly, which is way more than I would expect from attempting to run a DirectX game on Linux.

There is also no need for a no-cd-crack, you can use the official executable. When you run the update program it will patch the game to the latest version (1.09 I believe), which eliminates the need to actually have the cd in your drive every time you want to play the game.

While on the subject of Linux Gaming, I feel obligated to mention there is a Doom III port that will run natively on Linux available from IDsoftware's FTP Server. There's also tons of other goodies on there so make sure to give those a glance as well. I personally installed the doom3 package available in the Arch User Repository, but I have used the version available on the FTP server before on Mint, Ubuntu, and Debian successfully.

Note that you will need to copy files pack000.pk4 through pack004.pk4 from the retail version to your Doom 3's base directory (there is a directory named 'base', I am not referring to Doom 3's root directory) on the Linux box in order for the game to work (What, did you think they were giving it out for free?). If you bought Doom 3 through Valve's Steam, the needed files will be in your ...\steamapps\common\doom 3\base folder, otherwise just search for files with a .pk4 extension via your favorite method. Now as for cd keys...

I bought (yes really, no warez here) Doom 3 via steam. When you launch it the first time it displays a cd key, which I'll call key-A. It also creates two files in your Program Files (x86)\Steam\steamapps\common\doom 3\base folder called doomkey and xpkey, both of which contained different keys, which I'll call key-B and key-C. All 3 keys are 16 characters, and when the Doom 3 port launches, it prompts you for a 16+2 digit key. So now I have three separate, and equally useless keys. I sent an e-mail to Steam's customer support asking for a new key, but I doubt they'll be scrambling to help out a Linux user, so I had to rely on a little MacGyver-ing to get Doom 3 running.

For some reason, id Software chose not to disable console access while the key prompt was up. Maybe this was intentional, maybe not, but either way it allows you to circumnavigate the key-verification process which is legal provided you have actually purchased the game and corresponding cd key. So when I launch Doom 3 on Arch, I am greeted with the rather annoying prompt. Then I just ~ into the console and 'map game/delta4' (or any other map for that matter), and it will set about loading that map, thus circumnavigating the buggy cdkey authorization prompt. It's a hack, but at least I can play Doom 3 on Linux now.

NOTE: This will not help you play the game without purchasing it. You will still need to supply the .pk4 files mentioned above from the purchased version in order to play, the method I have provided is merely a means of circumnavigating a process that can prevent legitimate Doom 3 owners who have legally purchased their copy of the game from playing it on Linux, which they are entitled to do as it does not violate the terms of the EULA.

id Software is the only game company I know of that actually ports their games to Linux, and makes the ports freely available for users who have already purchased the Windows version. As such, you should actually buy id Software's games and show your support for their actions. There is currently an ID Super Pack available on steam for $70, which is an unfathomable deal considering you get over 20 games including the DOOMs, Quakes, Hexens, Heretics, Wolfensteins, and more. And no I do not benefit in any way from you doing that. I just like to support companies that support me, and by porting their fantastic games to Linux, id Software has done just that.

UPDATE: April 10th 2010
Here's how to fix the cd-key issue. Copy the doomkey and xpkey files to your ~/.doom3/base directory. Special thanks to Filip Oščádal of www.mxd.cz for the solution.