Performance tips and tweaks for the Linux version of SimCity 3000 Unlimited

Contributor/author(s): Craig McPherson

The Linux version of SimCity 3000 Unlimited is published by Loki Entertainment (http://www.lokigames.com/). This document is concerned mainly with performance tips and tweak, but also includes some basic information on said version. All information herein is based on my personal experience, and your mileage may vary. This is meant mainly for lower-end systems that need help to run the game at an acceptable performance level. If the game runs flawlessly on your brand-new system, you can follow or ignore any of this advice freely.

GENERAL INFORMATION

The Linux version of the game is identical to the Windows version, except where changes were necessary (ie the save/load dialog boxes), however the installer is entirely different. There are minor differences in the packaging (no CD key, the manual and CD case are Loki-branded, etc). Loki's version is available in 9 languages. See their website for a list.

Since Loki Entertainment is the publisher rather than Electronic Arts, Loki is your source for support and other issues related to the game. EA will not say anything about the Linux version beyond providing links to Loki's website. If you need support, visit Loki's support page (http://www.lokigames.com/support/). If you can't find the information you need on their website, they have a support e-mail and telephone number (not toll-free) listed there. I've never had to e-mail Loki for support, but I've heard they're extremely helpful, so if you have problems give it a try.

Saved games should be completely compatible between the Linux and Windows versions. The Linux version includes Building Architect Plus, and all building files should be cross-compatible. Third-party add-on programs, trainers, etc. written for Windows will not run on Linux. The Linux version can not import SimCity 2000 cities, however Loki's website says that if you e-mail them your SC2K city, they will convert it to SC3KU format and send it back to you.

GETTING THE GAME

I would assume if you're reading this, you already have the game, but if you don't, I'll provide a few links. First, you can order the game directly from Loki (http://www.lokigames.com/orders/), but I've heard that the company that handles their orders can be somewhat unreliable, so you may want to give that a pass. Tux Games (http://www.tuxgames.com/) is an excellent place to order the game, and should ship to nearly anywhere on this planet. Amazon (http://www.amazon.com/ or http://www.amazon.co.uk/) carries the game also: search for "Linux SimCity".

I've heard that Loki is offering a 50% discount to Linux User Groups (LUGs) who purchase 10 or more copies of the game. Check Loki's site for details.

SYSTEM REQUIREMENTS

I ran the game on a P2/233MHz with 64MB RAM. The box lists the minimum system requirements as 233MHz with 32MB RAM, but I wouldn't really recommend trying that -- if you do, please pay special attention to my tips below on freeing up memory.

In terms of software, the game should run on any up-to-date version of any distribution. You must be running kernel 2.2.x or higher (2.4.x should work fine) using Glibc-2.1 or higher, with version 3.3.5 or higher of XFree86 (XFree86 4 should work fine, and I assume other XServers such as MetroX would work as well if they're up-to-date, but check with Loki to be sure). If you don't know what all this means, don't worry: any distribution released in the past year or so will meet those requirements. X must be running at at least 640X480 with 16-bit color. If you don't have X set up properly, see your distribution's documentation on configuring the X Window System, or try out the Xconfigurator program (on Redhat-based distros) or XF86Setup (on any distro). If the X Window System is already working properly on your system, don't mess with the configuration unless you know what you're doing.

If you want to use Building Architect Plus, you must be using an OpenGL-compliant 3D driver for your video card. I haven't used it, so I can't offer any advice here.

If you want sound in the game, you must have your sound card configured and working in Linux. If you haven't done this, check the Linux Sound HOWTO (http://www.linuxdoc.org/HOWTO/Sound-HOWTO/) or your distro's documentation. If you're using Esound (ESD), read the relevant section in the FAQ (http://faqs.lokigames.com/faq.php3?view=index&product;=SC3K) about OpenAL.

If you get skipping or stuttering sounds in the game also see the relevant section in the FAQ.

INSTALLING THE GAME

I recommend installing the game under /usr/local or /opt. Make sure you have at least 230MB free on the partition that you want to install the game to, preferably more, so that you can copy music and other data files to your hard drive for better performance. You will need to be logged in as Root in order to install to /usr/local or /opt. If you don't have Root privileges on the machine, you can install the game to your home directory.

Saved game files will always be stored in the home directory of the person running the game. If user Bob plays the game and saves a city, then user Bill runs the game, Bill will not see Bob's saved city, because Bill's cities are stored in /home/bill/.loki/sc3u/cities, and Bill's cities are stored in /home/bob/.loki/sc3u/cities. Of course, cities can be copied freely between directories by anyone with the privileges to do so.

The Install Guide comes with step-by-step instructions for installing the game. You simply run the installation script, and one of two things will happen. If you run it from a text console, or from a shell in an xterm that doesn't know it's running in an xterm, you'll be asked several questions and then the game will install. If you run the install script from an xterm, you'll get a graphical install window. Just set the options how you want then select "Begin Install". The options are the same no matter which version of the installer you use. I'll comment on a few of them.

Install Path - This is where you want to install the game. If you're installing the game from a non-superuser account, you'll have to install it some place that you have write access to, like your home directory (install it at /home/bob/SimCity, or something like that). If you're root and want any user on the machine to be able to play the game, you should install it to the default, /usr/local/games/SC3U, or something simpler like /usr/local/SimCity.

Link Path - This should be a directory in your PATH. A symlink to the game will be created here, so that you can start the game by just typing "sc3u" from any directory. If you're root, you should put this in /usr/local/bin, assuming you have the directory in your PATH (if not, you should add it).

Install Options - You can install optional components to the hard drive to speed up the game, if you have the space. You can also install Building Architect Plus here.

Once you've got the game installed, assuming you set the "Link Path" option to something in your PATH, you can just type the "sc3u" command in an xterm to start the game. Or you can explicitly start the game with this command, adjusting for wherever you installed the game:

/usr/local/games/SC3U/sc3u

However, before trying out the game, you might want to read the rest of this document.

PATCHING THE GAME

You should do this. On my system, the game would not even run until I installed the patch. The README claims that the patch fixes a lot of problems.

You can get the patch either by using the Loki Updater (http://updates.lokigames.com/). If you're in a hurry or don't want to install the Loki Updater, you can download just the SimCity 3000 Unlimited patch via anonymous FTP from ftp.lokigames.com, in /pub/updates/sc3u

PERFORMANCE TWEAKING (This is what this whole document is supposed to be about, so it's time to get started)

Tweaking Topic #1: FREEING UP RAM AND CPU CYCLES

Just like in Windows, this is the most important thing you can do to improve performance, and just like in Windows, it involves mainly shutting down background processes.

A. Examining memory and CPU usage.

The first thing you need to do is familiarize yourself with the top command. Starting it is simple: type top in any shell. You'll see a list of all running processes, sorted by how much CPU time they're currently using. I'm going to discuss CPU usage in an upcoming section, but for now you want the list sorted by memory usage rather than CPU time.

To switch top over to show memory usage, type a capital M while in the top program -- that is, hold shift, tap the M key, and wait a few seconds. The processes will reorder, with the largest in terms of memory at the top. The %MEM column shows what percentage of system memory each process is taking up.

Press Control-C to exit top.

Likely, you have more processes running than will fit on the top screen. To see a full list of running processes, use the ps aux | more command.

These commands will show you what processes are using RAM and CPU cycles, but you likely don't want to go killing processes at random, so read on.

B. Seeing memory statistics.

Run the free command in any shell to see memory statistics. I've reformatted an example output for purposes of clarity.

LINE 1: Mem: Total 62380 Used 61136 Free 1244 Shared 26792 Buffers 1320 Cached 22144

LINE 2: Used - Buffers/Cache 37672 Free + Buffers/Cache 24708

LINE 3: Swap: Total 393200 Used 19968 Free 373232

What does all this mean? The MEM line refers to physical memory in the system. The SWAP line refers to virtual memory, or swap space. All numbers are in Kilobytes. In the MEM section, Total is the total amount of RAM in this system -- in this case, about 64MB. Used is the amount of RAM that's in use, and Free is the amount of RAM that is not. Don't be surprised if nearly all your RAM is in use -- this is a good thing. Linux uses all but a tiny bit of your free RAM to improve system performance by caching and buffering. The true amount of free RAM you have is equal to the Free amount plus the Buffers amount plus the Cached amount -- which is conveniently added up for you on the second line. In this case, there's about 24MB free, even though only about 1.2 MB are actually unused. That's perfectly okay.

The SWAP line shows the total amount of swap space on your system, the amount in use, and the amount free. If no swap space is in use, that's good: everything running on your system fits into normal RAM. Accessing swap space slows things down tremendously: the goal of freeing up physical RAM is to make it less necessary to use swap space. On this system, a total of about 20MB of swap space is used, out of a total of about 400MB.

You should aim to have zero swap space in use and as much free memory as possible before starting SimCity 3000 if you want the best possible performance.

C. Startup processes, and your distro's Init system.

Like with Windows, you probably have many many programs run automatically when you start your computer, most of which you don't know about, and many of which you don't need running. In Linux, these are generally called "Services", even though not all of them are actually "Services" by the traditional definition -- but I digress. I'm going to briefly describe how to kill some of these startup services. I'm not going to go into how to stop them from starting up during bootup, because it's beyond the scope of this document. I could describe the "standard" way, but many distros have much simpler distro-specific ways, so I won't bother. Check your distro's documentation.

Startup Services are handled by the INIT SYSTEM. The Init system (short for Initialization) is a superprocess that handles not only Startup Services, but creating login screens and doing other important system functions. The Init system I'm about to describe is the SysV init system that's used my most Linux distributions. Slackware uses the BSD init system, which is rather different. Once again, consult your distro's documentation.

Under the SysV init system, scripts for starting and stopping Startup Services are kept in an init directory. In Debian, this is /etc/init.d. in Redhat-based distros, this is /etc/rc.d/init.d.

Now, say you want to shut down some of the stuff that you saw running in the top program as described earlier. Let's say you saw Apache (called Apache in Debian, or Httpd in the Redhat-based distros) running, and now you want to shut it down by using its init script. You do it like this:

(Debian) /etc/init.d/apache stop (RedHat) /etc/rc.d/init.d/httpd stop

You can shut down any other Startup Service that way, but substituting its name for "apache" or "httpd" in the above example. For example, if you want to shut down Cron, you can do it like this:

(Debian) /etc/init.d/cron stop (RedHat) /etc/rc.d/init.d/cron stop (your distro may call it crond instead of cron)

You can restart a service that you've stopped in much the same way:

(Debian) /etc/init.d/cron start (RedHat) /etc/rc.d/init.d/cron start

D. Startup Services that you SHOULD shut down.

Now that you know how to shut down services, let's go over some that you really should shut down if you're going to play SimCity.

CRON - This is a sort of "task scheduler" that runs commands in the background at regular intervals. For example, on your system Cron may index your files once a week, rotate your logs once a month, and perform any number of other tasks. You don't want this stuff happening while you're playing a game! Some of the things Cron does can bring a system to a crawl, and although Cron is usually set up to do these things at 3AM or so, who really HASN'T played SimCity at 3AM? Better to shut cron down completely before you start playing, then start it again when you're finished. Remember, init scripts are usually all lower-case, but I capitalize words like Cron here just to make things easier to read.

ANACRON - This is another program like cron. Shut it down also so it doesn't rudely interrupt your game.

INETD or XINETD - These are Internet superservers. Your distro will use one or the other, but not both. Whichever one it uses, shut it down.

APACHE, SQUID, MYSQL, or any other heavy-weight server program - These consume a ton of RAM, and don't need to be running while you're playing a game.

Any distributed computing program - Such as Distributed.Net or SETI@Home. These are supposed to not take any CPU time when the CPU is completely in use by another process (like SimCity), but in reality, they always eat a tiny slice, and they take up a fair chunk of RAM. There's no need to have them taking up RAM when they're not doing any good, so shut them down. If you have one of these running but NOT from an init script, see the forthcoming section on killing processes.

Any other un-needed service that's using a lot of RAM - Check with top and ps aux as described above. Remember, even if a process is only taking up 1% of your RAM, 30 such processes can quickly add up.

E. Killing processes that aren't controlled by an init script.

You can kill any process by following this method. If the process is a Startup Service controlled by an init script, it's better to shut it down using the init script, to make sure you get a "clean" shutdown, but this will let you kill ANY process. (Disclaimer: try not to kill things if you don't know what they are. Some processes, like init, kflushd, and the other "k-services" have to be running at all times)

Step 1: Get the processes PID (process ID). You can get this from the top or ps aux command.

Step 2: Use the kill command, with the PID as an argument. For example, to kill process #31221, you'd do this:

kill 31221

Step 3: Check to see if the process is still running. If it's still running a few seconds after you tried to kill it, you'll have to forcefully kill it, like this:

kill -9 31221

That will kill any process except for zombie processes, which don't hurt anything anyway. Don't use kill -9 unless a normal kill fails, because a normal kill gives the process a chance to clean up and shut down properly, whereas a kill -9 doesn't.

F. Don't kill your X server or Window Manager!

SimCity only runs inside the X Window System. The process on your system that takes up the most memory (unless you're running Netscape or something equally bloated) is the X server itself. X is just a memory hog, and there's nothing you can do about it. Another process that's probably taking up a ton of memory is your Window Manager. If you're using KDE, you may want to temporarily switch to something lighter like ICEWM. I talk more about this later.

G. Common Sense

Don't try to run SimCity while Netscape or StarOffice or something similar is running. Duh.

Tweaking Topic #2: SWAP SPACE

You probably already know what Virtual Memory is and how it works. Technically, Linux doesn't do Swapping, it does Paging, which is a more advanced form of Swapping, but both terms are used mostly interchangeably.

This section deals with both making sure you have enough swap space to run the game, with strategies for fastest swapping, and with procedures for adding and removing swap space.

A. Seeing how much swap space you have.

Again, use the free command. You'll see how much swap space you have total, how much is in use, and how much is free. As I said, it's best to not have any swap space in use before starting SimCity -- shut down memory-hogging processes, and you should see the amount of swap space in use go down.

B. How much swap space should you have?

SimCity kept crashing at regular intervals while I was playing. This was quite annoying, but I could recognize it was about to happen and usually save my game in time, because my hard drive would start thrashing and the game would slow to a crawl.

After putting up with this for a while, I waited until the game started acting like it was about to crash, then I quickly switched to a text console and ran the free command. 100% of my swap space was in use: the game had eaten up all my swap space, and when there was no more left to take, it couldn't continue running and crashed.

But I had 196MB of swap space active at the time!! Whether the game contained a memory leak or just some very bloated code, it was chewing through 196MB of swap space after just a few hours.

So how much do you need? More than 196MB, I suppose!

I doubled my swap space by creating a 196MB swap file (see below), and the game never crashed after that. So if the game never crashes on you, you probably have enough swap space. If it DOES crash, lock up, or otherwise act anti-socially, try adding more swap space.

C. Maximizing swap performance.

In Linux, swap spaces come in two varieties: swap partitions and swap files. Swap partitions are the most familiar to most people, but I find swap files to be MUCH more convenient and flexible: you can quickly add, delete, activate, and deactivate as much or as little swap space as you need without re-partitioning your hard drive.

Swap partitions are fastest when placed near the beginning of a hard drive, because it'll physically be located near the center of the drive, which can be read faster. They should also be located close to other partitions that'll be in heavy use, so the disk head doesn't have to skip around so much: if your main Linux partition(s) is/are at the front of the drive, then the rest of the drive is filled with Windows partitions that you're not using at the moment, and your swap partition is at the very tail-end of the drive, the drive head is going to waste a lot of time moving back and forth between the two active areas of the disk. Don't worry too much about this stuff, though: it's not worth re-partitioning your drive just for a small possible increase in performance, but keep it in mind for the future.

If you have multiple physical hard drives, you should have some swap space on each of the drives. Linux will do "load balancing" between the drives, which will give you a performance boost. This is not terribly effective with IDE drives, but on a SCSI system where multiple drives can be accesses at the same time, the performance increase can be large.

D. Adding more swap space.

You add a swap partition like this:

1. Create the partition in fdisk (if you don't want to re-partition your hard drive, use a swap file instead. If you don't feel safe doing any of these steps, use a swap file instead!! If you toast your partition table, I will not accept any responsibility!)
2. mkswap /dev/hda4 (substitute the device name of your new swap partition -- make sure you get it right!!)
3. swapon /dev/hda4
4. echo "/dev/hda4 none swap sw 0 0" >> /etc/fstab
5. Run "free" to make sure your new swap space is active.

You add a swap file like this:

1. dd if=/dev/zero of=/var/swapfile1 bs=1048576 count=64 (replace 64 with the number of megabytes you want your swap file to be)
2. mkswap /var/swapfile1
3. swapon /var/swapfile1
4. echo "/var/swapfile1 none swap sw 0 0" >> /etc/fstab
5. free

You can add as many swap files as you like. Call them swapfile1, swapfile2, swapfile3, etc.

Tweaking Topic #3: OTHER STUFF

A. Use a lighter Window Manager

KDE (technically a Desktop Environment and not a Window Manager, but I'm trying to keep this document non-technical) eats up a ton of RAM. So do GNOME, Enlightenment, Windowmaker, etc. The lightest Window Managers are Icewm and FVWM. You should consider using one of them, at least when you're going to be running SimCity. Note: I don't mean run Icewm inside of KDE, I mean run it INSTEAD of KDE.

Check your distro's documentation on how to switch Window Managers, because each distro does it differently. In Debian, you can simply put "icewm" as the first and only line of your ~/.xsession file.

B. Disk de-fragmentation.

This isn't necessary with Linux's ext2 filesystem. Still, there IS a defrag program for the ext2 filesystem. In my experience, it's very usable and stable, however, it's really not needed unless you have a filesystem that's been in heavy use for years. I don't use it on a regular basis, because I figure it has at least a 1-in-100000 chance of toasting the filesystem, and over the years that can add up. If you're a compulsive defragmenter, go ahead, knock yourself out. I won't tell you where to find the program, though.

C. Recompile your kernel.

You can free up a bit of RAM, and possibly get a good speed boost, if you custom-compile your kernel for your system. This is an easy but somewhat complex process, so I can't go into detail here. Check the Linux Kernel HOWTO (http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html) for the basic procedure, or check your distro's documentation -- many distros have a simpler procedure.

D. Remove unused kernel modules.

If you're really desperate for more RAM, you can squeeze out a tiny bit more by doing this. Use the lsmod command to see that modules are currently running, then use rmmod to remove any that you don't need running at the moment.

E. Log out of any consoles before running the game.

If you're logged into any text consoles, log out of them before starting SimCity -- each of them takes up some RAM. The only shell you should have open is the xterm you're running SimCity from, if you're running SimCity from an xterm.

F. Consider the ReiserFS filesystem.

ReiserFS is a high-performance filesystem that can replace Linux's ext2 filesystem. Advanced users should look into it, because it's very cool. New users should steer clear, unless your distro has built-in support for it. Some new versions of some distributions allow you to create ReiserFS filesystems during initial system installation, simplifying the process tremendously.

FINAL THOUGHTS

I hope that this document was useful to you. If you have any questions or comments about it, feel free to e-mail me at craig@bsu-hog.org.

IMPORANT LINKS

Loki Entertainment: http://www.lokigames.com/
Loki's SimCity 3000 Unlimited: http://www.lokigames.com/products/sc3k/
Loki's SimCity FAQ: http://faqs.lokigames.com/faq.php3?view=index&product=SC3K
LinuxNewbie: http://www.linuxnewbie.org/ - a very useful site for Linux questions and help