At least SimCity 3000 still works

In a fit of optimism, I did a little more playing with Tuxracer tonight. It still doesn't work. On the up side, I was at least able to get all three of my Loki games to work.

I have copies of Loki's ports of Quake III Arena, Railroad Tycoon II, and SimCity 3000 Unlimited. Both Railroad Tycoon and Quake 3 still work perfectly on Kubuntu Breezy. However, SimCity needed a little research.

The straight-off-the-CD installation of SimCity didn't work at all. It bombed out every time with a message about an invalid glibc version. Fortunately, there is a version 2.0a patch for SimCity, which I still have a copy of. Applying the patch didn't work right away either - I got a message about invalid usage of trap. However, when I ran the patch with bash filename instead of sh filename, it worked. Probably a bug caused by bash using sh compatibility when invoked with the sh symlink.

Anyway, after installing the patch, it still didn't work - I just got a segfault. However, I found the answer in this post on Ubuntuforums.org. It turned out to be as simple as telling SimCity to assume a different version of the kernel. I just started it with the command following command, and it worked perfectly:
LD_ASSUME_KERNEL=2.4.2 /usr/local/games/SC3U/sc3u

So that's three out of four proprietary games still working. If I ever get a better video card, maybe I can make it four out of four. Of course, if the games were open-source, I could try to fix them myself, but I guess you can't have everything.

Desktop search?

What with "desktop search" being one of the catch phrases this year, I've been meaning to try out Kat, a KDE-based desktop search tool. I finally got around to it tonight.

The reason I never bothered to try Kat up until now is that I used to use Slackware. Kat depends on inotify, which is a relatively recent kernel feature. So, to make Kat work on Slackware, I would have had to upgrade my kernel, which was, frankly, just too much work. However, now I'm running Kubuntu Breezy, which has an inotify-enabled kernel and pre-buitl Kat package. So, I installed it.

When you start Kat for the first time, it takes you through a setup wizard. This wizard checks that inotify is working, starts the Kat daemon, and checks for the various helper applications that Kat needs to extract data from various file formats. There are over a dozen helper programs listed, and while I only had two installed initially, all but one of them is in an Ubuntu repository.

Step 4 of the setup wizard guides you through. Or rather, that's what it says on the screen. In fact, it just dumped me at Kat's main screen and that was it. Apparently creating a catalog is pretty self-explanatory, because the Kat homepage didn't have any documentation on it either. I didn't really know what to do, so I just gave the catalog a name, my home directory (for the location to index?) and told it to auto-update, whatever that means.

At this point, I'm not really sure if this was a good idea. The Kat daemon which is, apparently, a KDE service that handles the file indexing, seems really dodgy. I'm not sure how it works, but it keeps stopping for no apparent reason and I now have two icons for it in my system tray. It also took me about three tries before it actually indexed any files. And when it did start working, it gave me this ominous looking progress bar that never got above 1%, along with an 11 hour time estimate and a box that refered to a file size of 719MB, which I fear may refer to the index size.

What little I've seen so far suggests that Kat might be marginally useful, if it ever finishes indexing my files. Perhaps it just needs some time to mature. I guess I'll know more in a day or two, when it's finished indexing enough files to be useful.

Reworking AutoFS and media:/

This week I decided to re-evaluate my approach to removable media. For a while, I had been using a combination of my old Slackware automount config with ivman for autorun functionality. This worked well enough, but it wasn't terribly satisfying.

The behavior I really wanted was almost what Kubuntu Breezy uses by default, i.e. when you insert a new removable device (including CDs and USB drives), an icon is added to your desktop and the device is opened in a file manager window. The only problem with this is that Kubuntu uses the old "static" mounting approach, as opposed to automount. This, of course, introduces the limitation that you have to either manually unmount a device before removing it, or just pull it out while it's still mounted and hope for the best. I don't like that.

My personal feeling is that removable devices should be more or less like they are in Windows, i.e. the user shouldn't know or care whether a device is mounted. A device should be transparently mounted when it is accessed and unmounted when it is not longer in use. I don't want to have to "safely remove" a USB drive that doesn't need to be safely removed. Likewise, I don't want right-click on a CD drive icon to unmount and eject the disk when I can just push a button on the drive. And, quite frankly, I'm sick of UNIX desktops treating this like a perfectly normal and natural thing to do.

So, on to my solution to this problem. The main problem was getting some good dynamic desktop icons. The ones built into KDE are good, but they operate with the media:/ IO-slave, which assumes static mounting. I briefly tried writing a script to dynamically create desktop files, but quickly realized that I didn't have enough time or interest to write anything as full-featured as what KDE already has. So, clearly, the best way to proceed was to get KDE to use my autofs mount points instead of media:/ URIs.

This part actually proved much easier than I expected. It turns out that KDE has MIME types for removable media, such as media/removable_mounted and media/dvd_unmounted. Like any other MIME type, you can change the file associations for these. So all I needed to do was come up with a simple script script to convert the media:/URI that gets passed to the file handler program into an autofs mount point.

The only problem here was that my old automount configuration used static mount points like /var/autofs/optical/cdrw. The URIs my script gets as parameters, however, look like media:/hdc. I could just implement a simple look-up table, or do some trickery with udevinfo or symlinks in /dev, but I wanted something more natural and extensible. So how could I make that conversion without doing something overly complex or ad hoc?

The answer is: I couldn't. However, I could adjust my automount configuration to make writing the script trivial. I do this by taking advantage of the wildcard feature of automount. Basically, automount allows you to have entries in your map files that use "*" as the key and "&" as a substitution character for that key.

This allows me to dramatically simplify my map files. For instance, the /etc/auto.removable file, which defines automount points for my USB storage devices, used to have 4 entries - one for each USB storage device I own. The new one has a single entry:
* -fstype=auto,sync,user,umask=0000 :/dev/&
This simply matches a key name to a device node. So, e.g., when I access /var/autofs/removable/hdc, automount will mount /dev/hdv on that directory.

So now I can much more easily match a media:/URI to an automount point. Now, media:/sda1 will be mounted on /var/autofs/removable/sda1 and, thanks to a similar map file for CD and DVD drives, media:/hdc will be mounted on /var/autofs/optical/hdc.

Given this, my handler script for media MIME types becomes clear.
#!/bin/sh
Branch=`echo "$2" | sed 's/media:\/*//'`
kfmclient openURL /var/autofs/$1/$Branch

All it needs is two parameters - the autofs map to use and the media:/ URi. I simply hard-code the appropriate map in the file association for each MIME type and I'm all set.

The only other thing to do is fix up the autorun functionality. Kubuntu Breezy uses ivman to mount newly inserted devices and then open the media:/ URi in Konqueror. Fixing this involves editing the /etc/ivman/IvmConfigActions.xml file. Luckily, this file is well commented, so fixing it is easy. Just delete or comment out the section that tries "to mount any mountable volume at all" and change the "open konqueror" rule to use kfmclient exec instead of kfmclient openURL. That will cause kfmclient to use the modified file association instead of going straight to the media IO-slave.

That pretty much does it. I've only found one problem, which is both significant and weird. After inserting a new device, when I click on the desktop icon the first time, it opens using my autofs script. However, the second time I click it, it opens with a media:/ URI instead. If I refresh the desktop, I can open the device with my script again, but only the first time. But if I use the right-click "open" menu item, it works correctly every time. It makes no sense. I think I'll be working on that for a while.

Tuxracer DOES still work

It looks like I need a new video card.

For a while now, I've been having a problem getting Tuxracer to work. It's important to note here that I'm talking about the "deluxe" version of Tuxracer - the one that was sold commercially by Sunspire Studios for a few years. This is the version that they claimed they were going to open-source after they had made their money, but didn't. And since it seems that Sunspire is now out of business, they probably never will.

Anyway, a few years ago, I shelled out the $15 for a copy of Tuxracer Deluxe. It's considerably better than the free version, and was well worth the price. However, at some point it stopped working.

I think it was the change from XFree96 to X.org that broke it, but I'm not sure. All I know is that, somewhere along the line, the game got unplayably slow, despite the fact that direct rendering appeared to be working properly. It was more or less OK up until I started a race, but at that point, the video slowed down to, let's say, 1 frame every 20 or 30 seconds.

I figured that the game was broken on new software, but every now and then I get the urge to try it out. I never had any success on my machine with the el cheapo 16MB Rage 128 card. Today, however, I decieded to give it a try on Sarah's Xandros box with the 64MB Radeon 7000 card. And you know what? It worked flawlessly. Apparently it's just the X.org Rage 128 driver that's broken. Oh well. On the up side, I can get a Radeon 7000 for around $30.

Playing with ePSXe

A month or so ago, I decided to take advantage of the new hardware I bought this summer and take another go at an emulator I'd been playing with. I'm no stranger to emulators, but the this time I was interested in emulating a PlayStation, which took a bit more horse-power than my old system could manage.

The emulator in question, ePSXe, is a nice little cross-platform emulator with a GTK+ graphical interface (at least in the Linux port - I've never used it under Windows). However, it's rather hard to set up because the emulator itself doesn't actually do any useful work. All the graphics, sound, and joystick support are done through a plugin interface, and ePSXe doesn't come with a default set of plugins. Normally I would complain about how stupid this is, but since game console emulation is one of those legal gray areas, I'm willing to overlook this shortcoming.

I found a nice little tutorial on ePSXe to help me through the configuration process. The only part it didn't help with was finding a BIOS image, which I already had from playing around with it a couple of years ago.

There were a few snags I ran into in my ePSXe adventure. First, I was only able to get the SoftX video driver to work. The Mesa GL driver just froze the emulator on my system. I didn't play with it long enough to be sure, but I suspect it's related to my ultra-cheap 16MB Rage 128 video card.

My second problem was also related to video. There was a small but noticable lag when playing in my preferred mode - an 800x600 window. Apparently the video scaling just wasn't fast enough. The only way I could fix it was by dropping back down to low resolution. This, of course, required me to play in full-screen mode, because playing a game in a 320x240 window on a 15 inch monitor when you're near-sighted just isn't feasible.

So far, my experience has been mixed. Fortunately, I have had no trouble at all with Final Fantasy Tactics, which was the one game I really wanted to work. I've seen minor text glitches in Castlevania: Symphony of the Night, but nothing big. The lack of a start button on my gamepad is more of a handicap than any bugs. However, Um Jammer Lammy was completely unplayable and I had some problems with PaRappa the Rapper (yes, I know they're both extremely lame, but I don't care). I haven't tried any other games yet, but apart from the Final Fantasy series, I don't own many other PlayStation games.

So, all in all, a good experience. I can play the one game I really cared about with state saving, so I'm happy.