Things are looking up for Linux game support

22 10 2007

While Linux probably isn’t quite ready to be a operating system choice for gamers, Linux users who happen to want to game are in for a treat.

Recently released was a native client for Enemy Territory: Quake Wars which I have been having fun playing the last couple of days. Many people have been claiming it as a BF2 rip off (mostly BF2 players) however the gameplay itself is completely different even if there are quite a few similarities (plus BF wasn’t the first game to implement its class system or vehicles, just one of the more memorable, also its something that UT2003 already did). Its a much faster passed game so there is very little waiting in a corner waiting for someone to come and capture a flag or running across the map for 5 min until you get to one, although a lot of the team play has been stripped down but this just makes it play more like a standard FPS which isn’t bad, just different. There is a list of important to note differences for BF players here.

And out next month is Unreal Tournament 3 which is getting a native client, theres a Windows beta demo out and a Linux one on its way, when ETQW is mentioned people generally cry that UT3 is better, personally I’m going to buy both although its hard to tell from prerelease hype and a beta demo exactly how good a game is going to be. They both seem like great games, and since UT3 has both FPS and BF style gameplay it should be flexible enough to keep interest.

Source games such as Team Fortress 2 are working great under WINE with the same performance as under Windows (You might loose %5 but make up for it with lower lag, the advanced shaders can apparently be enabled with a setting if you want), with the whole Orange Box going for $50USD (About $56 AUD thanks to America ruining its economy). The latest version of Wine 0.9.47 runs Steam great, although I did run into a problem with purchasing Orange Box through PayPal since it opened PayPal in Firefox but then Firefox wouldn’t execute the steam://paypal/return command, I was worried for a while that it was going to charge me without adding the game but PayPal showed no payment, I coped out and booted to a windows partition and brought it through there but its probably possible to manually pass the command with something like “wine ~/.wine/drive_c/Program Files/Steam/Steam.exe paypal/return” or set the protocol association in Firefox to run the command but I haven’t looked at it too much. now I’m awaiting my TF2 and HL2E2 download, already beat Portal which was a fun game although a bit too short hoping there is a squeal in the not too distant future. Valve recently posted that job for a Linux games programmer and have already ported source to use OpenGL for the PS2 so we could see a native Linux client in the future.

EDIT: I just tried HL2:E2 seems to have some graphical problems with the shaders turning everything bright colours, running without them causes crashes however you can run with the game in DirectX 8 mode and loose some graphical detail, this is probably something that will be fixed fairly soon since it seems like a simple bug, they already fixed some similar problems with Portal.
EDIT2: Use wine 0.9.46 not 0.9.47 this works without the -dxlevel 80 flag, I had the same problem with TF2 that I did on HL2E2, works great with 0.9.46.

Wine’s seems to have most of DirectX emulated, the main problem is a few minor bugs that crop up in games, such as the mouse cursor being stuck or leaving the window etc… Most of the bugs that are left are minor but make games unplayable and are often specific to only the one game. Unfortunately there are enough of these that most games don’t run but its certainly getting there, presumably a lot of these are in the target for Wine 1.0

Wine is improving quite fast, probably faster than new specifications are being produced and with many games ensuring that DX9 is supported due to the slow adoption of DX10 and with the OpenGL 3.0 specification approaching release its might make implementing the DirectX>OpenGL wrapper a whole lot quicker since it seems to support many of the same features, we could see WINE running more games off the shelf than ones that don’t within a few years.

Virtualization could also be another great way to run games under Linux but with %100 compatibility although requiring a copy of Windows, all that would be needed is a way to allow direct access to the video card, this can actually be done under Xen but requires a 2nd video card since the first one will be locked by the BIOS at boot. Alternatively a DirectX>OpenGL wrapper in the windows install could work, I hear this is how parallels works using the WINE one, but it might sacrifice some compatibility and speed. OpenGL can already run from a virtualized environment with VMGL, with this and WINE’s DirectX it might even be possible already. Maybe some official support from nVidia/ATI would expedite things.

Theres some interesting history about WINE’s DirectX implementation and information about a DirectX 10 implementation being underway here.

QEMU for DOS abandonware under Linux

17 03 2007

EDIT: System Shock 1 is now working for me under kqemu, see end.

I decided I wanted to play some System Shock 1, unfortunately the game being several years old it no longer runs on modern system. There are emulation solutions such as DosBox (slow) and VDMSound (Windows only, I use Linux) however these have various flaws, bugs and compatibility issues, and even more problems when trying to run System Shock in particular. Unfortunately System Shock 1 wouldn’t work with sound but other games hopefully run better, the sound did work in Windows 3.1 🙂

So I decided that I would give QEMU a try, its a nice fast Emulator since it also supports virtualization it can run at almost native speeds. Works on both Windows and Linux. And since we are emulating the entire computer rather than trying to intemperate the OS specific instruction sets we can get close to compatibility. We do however need to install an OS.

These instructions are Linux based, however Windows also runs qemu so a lot of it is feasible, the main problem would be using the loopback floppy images.

First of all we need our OS, a copy of DOS, there are a few free choices around such as FreeDOS and OpenDOS. Unfortunately these are not 100% compatible depending on what software you are running you will have mixed results, apparently System Shock has problems running on FreeDOS due to some custom memory management by the developers and I would guess the other clones would have similar issues also.

There is also MS-DOS 7.1 which was the DOS shipped with Windows 98 repackaged, apparently that has some compatibility issues also.

I decided to use MS-DOS 6.22, many people have an old copy of the floppy disks lying around. It’s probably not legal to download although googling for shows many people think otherwise 😉

Once you have gotten your copy of Dos, you will either have real floppies or probably IMA disk images (they might arrive in self extracting archives exe’s, under Linux you can just use unzip to extract the files form the exe, wine would probally work too) , these images are supposedly in a DiskWrite format however they appear to be just basic binary dumps of the floppies the same you would get from running a ‘dd if=/dev/fda of=floppy.img’. ‘file DOSDISK1.IMA’ shows them as “DOSDISK1.IMA: DOS floppy 1440k, x86 hard disk boot sector”. IMZ files are just zipped IMA files so just unzip them.

If you are using original floppies, I recommend converting them to images with dd as images are a lot faster and floppies are fairly unreliable, its also handy to have backups.

The next step will be to crate a image for the File System:
qemu-img create -f qcow msdos.img 20G

This will create a 20G image, because we are using the qcow format the image file will only take the amount of space as the data we install onto it. 20G is excessive, a FAT16 partition can’t use that much space but its not using any disk space so the size is irreverent and you don’t want to give yourself to little space as you would need to resize the partition or probably format and start again, the other format choice raw is more compatible but for the FAT file system it will take the entire amount of space you give it. (Trying the new qcow2 format might also be an idea, my version of qemu didn’t have it as an option though)

If you are using disk images you will need to be able to access them as devices, run the following as root to bind them to /dev/loop0
losetup /dev/loop0 DOSDISK1.IMA

Now we need to boot the system with the qemu command (the faster ‘kvm’, Linux Kernal Virtualization Module version didn’t boot dos for me and crashed when Dos tried to initialize HIMEM (or directly after), I don’t have kqemu running so it might be worth disabling that if you have it installed and encounter problems. Stock qemu is slower but this stuff was designed to run on 33MHz so I don’t think there will be to much speed loss from the emulation layer, you can also use your real floppy drive with /dev/fda instead of /dev/loop0.
qemu -soundhw sb16 -cdrom /dev/cdrom -fda /dev/loop0 -hda ./msdos.img -boot a

You should get the MS-DOS 6.22 Setup screen, following the prompts it should partition and format the hard drive, reboot and then install.

When the setup asks for Disk2, if you are using images press ctrl+alt+2 and you will be in the QEMU monitor mode. Type eject fda This disconnects Qemu from the loopback floppy image so you can disconnect the image from /dev/loop0.
Pull up a terminal and losetup -d /dev/loop0

Now you need to bind disk 2 to loop0:
losetup /dev/loop0 DOSDISK2.IMA

Go back to QEMU and type change fda /dev/loop0

Press ctrl+alt+1 to resume the simulation and continue the Dos install procedure. Repeat for Disc 3.

When DOS has finished installing it will attempt to boot from A again, just remove the ‘-boot a’ line to make it boot from the hard drive and you should end up in a dos prompt.

Next is installing stuff. In order to transfer stuff from your local file system to the dos image, you need to run with the flag ‘-hdb fat:/your/driectory’, when I tried this I needed to be root. This will add an extra drive D: that maps to the directory specified, this allows you to put drivers and games in a directory and copy/install them onto the image under DOS. Otherwise you could try converting the image to a raw format (it will take the entire size of the image then), mounting on a loopback and copying the files across under Linux.

You will want to track down the sb16 drivers to get sound working, google for “sbbasic.exe” and install the drivers under dos. And for mouse drivers CTMOUSE works fine (its from FreeDos) otherwise any other PS/2 dos mouse driver will do. You might want to add the mouse driver to your autoexec.bat so you don’t have to run it every boot

There are also some video card drivers that allow Windows 3.1 to run in higher resolutions. Google “”

Now you can install and run games/programs.

Unfortunately System Shock doesn’t detect the audio correctly (It works fine in Win 3.1). But hopefully other games will work better. EDIT: System Shock 1 is now working for me under kqemu with sound. Autodetect does fail sometimes but if you try several times it works. I’ve noticed that SoundBlaster Pro doesn’t crackle like SoundBlaster 16 does. Use Adlib for the music. Sometimes the sound isn’t detected by the game either so you might need to restart if there if you hear nothing on the main menu. When trying to install the SoundBlaster 16 drivers I was getting a “Program too big to fit in memory” error, I think this was caused by having ‘–swhardware all’ rather than just ‘–swhardware sb16’. I also had problems with it freezing and giving me a blackscreen leaving the mouse locked to the window (ctrl+alt not doing anything) and even after killing qemu from another console the mouse was not working requiring xorg to be restarted with ctrl+alt+backspace. I don’t know what was causing that but making a new hdd image and installing from scratch fixed it, maybe not having a copy of Windows 3.1 installed helped.

Windows for Workgroups 3.11 under QEMU