Programming Linux Games

November 17, 2001 / Kurt Nelson / 0 Comments

Table of Contents

1. Origins of UNIX Gaming

1.1. Traditional UNIX Gaming

  • Mostly console based
  • BSD Games Collection (/usr/games)
  • MUD/MUSH servers
  • Cheesy X11 games
    • xbill, xboard (interface to GNU chess)
    • Nothing requiring sophisticated graphics
  • Nethack
    • Possibly the most addictive game ever written
    • Attempted Dreamcast port

1.2. Transition to Modern Gaming

  • UNIX traditionally has not been much of a “video” gaming platform
  • Workstation-oriented graphics, high-quality but not good for arcade-style
  • PC developed a gaming scene due to commodity hardware
    • Exploded with VGA graphics adapter
    • Although limited, chip had lots of potential
    • Smooth scrolling, decent color depth
  • Linux was still in its infancy; Xlib (slow) and SVGALib (bitchy) were the only options
    • SVGALib is a kickback to the mid 90’s; limited hardware support
    • Xlib is network-friendly and flexible, but not very fast
  • Doom and Abuse ported with SVGALib and X
    • Dave Taylor = Linux geek
    • Ported Doom, and when his now-defunct startup created Abuse, ported that too
    • Good ports, but finicky

1.3. Advent of 3D Accelerators

  • Much heavier reliance on driver support
    • battle used to be getting vendors to supply 2D programming specs
    • now 2D specs are easy; 3D specs are more difficult
    • at first, few vendors supported Linux
  • Programming specs are hard to acquire
  • First big step: Daryll Strauss ported Glide (3Dfx) to Linux
    • Brian Paul wrote Mesa, a decent software OpenGL implementation
    • Mostly complete and correct, but SLOW
    • Daryll Strauss convinced 3Dfx to let him port Glide
    • Soon Mesa was patched for Glide output, and became viable for games
  • Limited hacks to use Glide for accelerated OpenGL

1.4. Utah GLX

  • Proper integration of XFree86 and various 3D accelerators
    • Glide is not a general purpose graphics API, and often doesn’t play nice
    • SGI designed GLX specs, but Mesa + Glide didn’t really use it
    • Utah GLX is a hardware accelerated GLX extension for XFree86
  • Reasonably good performance, but lousy AGP support
    • lacked infrastructure for modern 3D accelerators
    • was still playing the catch up game
  • SGI released GLX source code, leading to better compatibility
    • Big publicity, not sure how much use it was, but much appreciated
  • Linux became a viable target for games; Loki released Heavy Gear II, Soldier of Fortune, and other Utah GLX oriented games
    • Precision Insight helped develop drivers

1.5. Direct Rendering Interface, DRI

  • Attempt to overcome intrinsic limitations in Utah GLX’s design
    • DRI has a lot to do with AGP memory allocation and management
  • Reached a point of stability about when Loki reached a point of bankruptcy
    • Loki spent a lot of effort trying to make games work on shaky OpenGL grounds
  • Excellent 3D performance on supported hardware
    • Support is finally getting there on many cards; still playing the catch up game
  • Requires DRM (Direct Rendering Manager) kernel module for memory allocation
    • DRM is an interface for allocating necessary memory buffers, mainly also requires AGPGART driver

2. The Linux Gaming “Industry”

2.1. The NVIDIA Menace

  • Seems to have a bad case of
    "not invented here"
    syndrome
  • Xinerama (dual head support) apparently not good enough for them; on their own with TwinView
    • Not really a problem, unless you want to do dual head with a non-NVIDIA card
  • Drivers share a codebase with Windows drivers
  • Developed in-house by NVIDIA, and reasonably well supported
    • Dedicated support staff, #nvidia on openprojects, frequent updates

2.2. The ATI Factor

  • It appears that ATI is sick of dealing with Precision Insight (commercial Linux video driver developer) and intends to develop drivers in-house
    • Precision Insight charges an insane hourly rate
    • Most of PI’s top employees have left
  • ATI does not have a good reputation for driver development, but hopefully something will become of this
  • Radeon 8500 is reportedly "schweeeeeeet"

2.3. Available Games

  • Fall into three categories: ports of Windows games
    (Loki,
    Tribsoft,
    Icculus),
    commercial games with Linux support from original developer
    (id,
    Epic,
    Sunspire), and hobbyist
    developments (FreeCiv,
    Stratagus,
    Worldforge)

  • Porting business is on shaky grounds; IT industry crash didn’t help
    • Don’t know if anyone is actually making money
    • Porting is a viable business as long as you don’t have to make money
  • Commercial support relies mainly on developer sentiments and off-hours hacking
  • Hobbyist development is the future
    • We’ve built a kernel, two major desktop environments, created the best firewall system ever…
    • … why can’t we make good games?
    • Lack of artists, perhaps?

3. Writing Linux Games

3.1. Simple DirectMedia Layer, SDL

  • Portable 2D video acceleration abstraction layer
  • Pass-through support for OpenGL; still useful in 3D games for input and audio handling
  • Sub-APIs for video, audio, input, threading, CD-ROM access, and file IO abstraction
  • Core of SDL is simple and tiny, but much additional functionality (image loading, high-level sprite management, etc) is available as add-on libraries
  • Strongest following of any multimedia toolkit

3.2. OpenAL

  • Portable 3D audio library; a mix of Creative’s EAX, OpenGL, and open source
  • Was doing quite well when both Loki and Creative were working on it
  • However, Loki is unable to continue support, so OpenAL has been stagnating
  • Some disagree with AL’s design, but I consider it clean and effective

3.3. OpenML

  • Corporate-backed portable multimedia library
  • Lot of potential, if the corporations can stay tame
  • Appears to be a bid to obsolete DirectX; if this happens, it won’t be for a while
  • Specification freely available

4. Resources