Linux Multimedia APIs und Game SDKs

Linux ist in aller Munde. Nachdem sich das freie Betriebssystem bereits einen Platz in der Welt Unix-Server erobert hat, macht es sich nun daran eine ernsthafte Alternative zu Desktopsystemen für Workstations und PCs zu werden. Der erste Schritt hierzu ist mit Desktop-Programmen wie KDE und Gnome bereits getan. Nun beginnen immer mehr Programmierer mit der Entwicklung von Treibern für Multimediageräte und die Entwicklung und Portierung von Multimedia-Anwendungen für Linux ist ebenfalls in vollem Gange. Dies ist eine direkte Folge des Vordringens von Linux auf Workstations und PCs. Speziell im PC-Bereich sind natürlich auch Computerspiele ein wichtiges Thema. Schließlich zeigt das Beispiel von Windows, daß gerade Computerspiele die Entwicklung von Grafik- und Soundhardware, -treibern und APIs vorantreiben. Dieser Artikel beschäftigt sich zuerst einmal mit den Grundlagen von Grafik und Sound unter Linux (und in eingeschränkter Form auch anderen Unix-Varianten) und versucht die besonderen Probleme, die bei der Benutzung von Multimedia-Hardware auf Mulitusersystemen entstehen, näher auszuleuchten. Im Anschluß daran folgt ein Überblick über einige interessante Grafik-APIs und Spiele-SDKs. Zu guter Letzt wird das Video4Linux-Projekt als eine interessante Multimedia-Bibliothek für Linux vorgestellt.

Auf Unix-Systemen und ihren diversen Derivaten gibt es seit jeher zwei Möglichkeiten der Interaktion von System und Benutzer. Zum einen die klassische Textkonsole mit Kommandoshell, zum anderen das X-Windows System, das ein grafisches Interface bereitstellt. Bei letzterem ist von Vornherein klar, daß das System in der Lage ist Grafik darzustellen, doch auch für die Textkonsole gibt es Grafikbibliotheken, in erster Linie die SVGALib. Diese bietet einen Zugriff auf Grafikhardware auf sehr niedriger Ebene. Ähnlich ist die Programmierung mit der XLib, wobei es viele weitere Bibliotheken gibt, welche auf der XLib aufsetzen und Highlevel-Programmierung ermöglichen (Stichwort Motif, GTK, QT, ...). Zwar ist die SVGALib wesentlich schneller, da sie im Gegensatz zur XLib ohne den Umweg über den X-Server direkt auf die Grafikhardware zugreifen kann, aber dies führt direkt zu einer eklatanten Sicherheitslücke im System. Jedes Linux-Programm das direkt auf Hardware zugreifen möchte benötigt entsprechende Rechte (suid root). Das Gewähren solcher Rechte an eine beliebige Applikation erfordert großes Vertrauen in den Hersteller. Im Falle des X-Windows Systems ist das Problem nicht so schwerwiegend, da die Applikationen ohne root-Rechte auskommen. Schließlich laufen alle Grafikaufrufe über den X-Server, der root-Rechte besitzt und dem man gemeinhin vertraut.

Das GGI-Projekt entstand aus dem Bestreben ein einheitliches Interface für alle Arten von Grafikausgabe und Benutzerinteraktion über Eingabegeräte zu schaffen. Das System soll schließlich als Backend für X- und Konsolengrafik dienen und eine strikte Trennung von User- und Kernelspace implementieren. Das heißt, daß alle Hardwareaufrufe in einem Kernelmodul, dem Kernel Graphics Interface (KGI), implementiert sind und alle abstrakteren Funktionen von einer Bibliothek, der LibGGI, zur Verfügung gestellt werden. Das Schlagwort hierbei lautet Sicherheit vor Geschwindigkeit.

		                        -------------
		                        | Programm  |
                        		-------------
		----------------          |       ^
		|    Kernel    |          |       |
		|              |          v       |
		|  ---------   |        ------------
		|  |  KGI  |<-----------|  LibGGI  |
		|  ---------   |        ------------
		|    |         |
		-----|----------
		     |
		     v
		----------------
		| Grafikkarte  |
		----------------
		

Man sollte nicht unerwähnt lassen, daß dieser Ansatz für Multimedia und Spiele einige Probleme mit sich bringt. Schließlich ist man dabei auf möglichst schnelle Grafikdarstellung angewiesen und aus dieser Sicht ist GGI nur ein Hindernis auf dem Weg zur Grafikhardware. Da die im Folgenden erläuterte Direct Rendering Infrastructure genau den umgekehrten Weg geht, ist es auch sehr fraglich, ob sich GGI als übergreifende Schnittstelle für XFree- und Konsolengrafik durchsetzen kann.

Links

http://www.de.ggi-project.org/

Die Direct Rendering Infrastructure der Firma Precision Insight ist die aktuellste Entwicklung im Bereich hardwarebschleunigte Grafik für Unix-Systeme. Für Linux-User ist interessant, daß diese Technologie auch in XFree86 4 integriert werden soll, dessen Erscheinen für das erste Quartal 2000 angekündigt ist. Um die Vorteile von DRI zu verstehen, muß man einen Blick auf die bisherige Grafikpipeline in XFree werfen.

In XFree werden alle Grafikfunktionen egal welcher Bibliothek in XLib-Aufrufe übersetzt. Für einfache Desktop-Anwendungen ist das nicht weiter dramatisch, aber für Multimedia-Anwendungen oder Spiele, die darauf angewiesen sind sehr schnell auf den Videospeicher zuzugreifen, wird der X-Server zum Nadelöhr. Hinzu kommt, daß XFree bislang nur wenige Beschleunigungsfunktionen der Grafikkarten nutzt. Der größte Teil der Funktionen wird in Software berechnet. Dieses Problem hat man eigentlich in Unix-Workstations schon seit Längerem zumindest teilweise gelöst. Die sogenannten GLX-Extensions ermöglichen es OpenGL-Aufrufe direkt an die Hardware (z.B. in SGI-Workstations) oder an einen modifizierten X-Server durchzureichen, ohne sie zuvor in XLib-Aufrufe zu übersetzen. Nun steht zwar mit Mesa eine freie OpenGL-Implementierung für Linux zur Verfügung und XFree kennt auch die GLX-Extensions. Allerdings werden bislang für die meisten Grafikkarten die GLX-Aufrufe weiterhin in XLib-Aufrufe übersetzt, weil geeignete X-Server fehlen. Einige wenige Karten für die ein X-Server existiert, der die 3D-Beschleunigungsfunktionen der Karte untertützt, sind

• Matrox G200/G400,
• nVidia Riva128/TNT/TNT2 und
• nVidia GeForce.

DRI geht noch einen Schritt weiter. Um maximale Performance zu erzielen wird der X-Server nach Möglichkeit vollständig umgangen. Dies ist in der Grafik oben links dargestellt. Desweiteren können nun Clients (d.h. Anwendungsprogramme) und X-Server auch über einen speziellen Speicherbereich (shared memory) unter Umgehung des X-Protokolls Informationen austauschen. Schließlich definiert DRI auch ein Kernelmodul das eine Übertragung der Grafikdaten per DMA-Channel ermöglicht. Einen Überblick über das Low-Level-Design von DRI gibt folgendes Schema.

	--------------------                --------------------
	| Client (*)       |                | X server (*)     |
	|                  |                |                  |
	|                  | <----PROTO---> |                  |
	|                  |                |                  |
	|                  |                |                  |
	|                  | <----SAREA---> |                  |
	|                  |        |       |                  |
	|                  |        |       |                  |
	--------------------        |       --------------------
	   |    |    |              |             |    |    |
	   |    |    |              |             |    |    |
	   |    |    |              |             |    |    |
	   |    |  IOCTL            |           IOCTL  |    |
	   |    |    |              v             |    |    |
	   |    |    |    --------------------    |    |    |
	   |    |    |--> | Kernel           | <--|    |    |
	   |   DMA        |                  |        DMA   |
	   | BUFFERS----> |                  | <----BUFFERS |
	   |              |                  |              |
	   |              --------------------              |
	  MMIO                      ^                   MMIO/PIO
	   |                        |                       |
	   |                    DMA/MMIO                    |
	   |                        |                       |
	   v                        v                       v
	--------------------------------------------------------
	| Graphics Device                                      |
	|                                                      |
	--------------------------------------------------------
	

Links

Precision Insight - DRI Designdokumente
SGIs GL-Extensions

Der Spieltrieb der Linux-Gemeinde treibt manchmal erstaunliche Blüten und auch wenn die ASCII Art Library etwas aus dem Rahmen dieses Artikels fällt, wäre er ohne sie auch nicht komplett. Die aalib nennt sich zurecht "The weirdest SDK" denn es handelt sich um eine vollständige 2D-Grafikbibliothek, die als Output nur ASCII-Zeichen kennt. Immerhin existieren bereits Anwendungen die die aalib benutzen, so das Demoprogramm bb oder auch eine Portierung der id-Spiele Doom und Quake.

     dT8  8Tb     
    dT 8  8 Tb    
   dT  8  8  Tb   
<PROJECT><PROJECT>
 dT    8  8    Tb 
dT     8  8     Tb

Links

aalib Homepage
Terminal Quake

Mittlerweile gibt es eine Vielzahl mehr oder minder portabler 2D-Grafikbibliotheken für alle möglichen Unix-Dialekte, wobei es sich dabei sowohl um freie als auch um kommerzielle Software handelt. Eine für Spieleprogrammierung gut geeignete Library ist Prometheus TrueColor - PTC. Es handelt sich dabei um eine reine Grafiklibrary für C++ Programme, die für diverse Unixe, Dos, Win32 sowie Java verfügbar ist. Außerdem ist PTC GGI-fähig.

Um kleine Applikationen mit komfortabler Grafikausgabe auszustatten bietet sich g2 an. Dabei handelt es sich um eine Bibliothek mit einfachen 2D-Grafikfunktionen, die die Ausgabe in verschiedensten Formaten unterstützt. Derzeit funktioniert die Ausgabe in ein X-Windows Fenster, sowie in GIF- und Postscriptdateien. Weitere Formate sind in Planung. Die folgende Abbildung zeigt schematisch das Konzept der virtuellen Devices, welches es ermöglicht mit einer festen Menge von 2D-Funktionen verschiedenste Ausgabeformate zu erzeugen.

                                   /-------> GIF:   g2_attach(id_GIF,..
            ----------------------- 
g2_plot---> | Virtual device: id |--------> X11:   g2_attach(id_X11,...
            -----------------------
                                   \-------> PS:    g2_attach(id_PS,...

g2 ist derzeit für Digital Unix, AIX, Linux, VMS und Windows NT erhältlich. Außerdem existieren Programmierschnittstellen zu Fortran und Perl, wobei letzteres g2 zu einer ausgezeichneten Wahl macht wenn es um Rapid Prototyping geht.

Zu guter Letzt sollte nicht vergessen werden, daß auch alle 3D-Bibliotheken in der Regel mit einem vollständigen 2D-API ausgestattet sind. So ist z.B. Mesa sicherlich sehr geeignet, wenn es um schnelle und effiziente 2D-Grafik geht.

Links

PTC Homepage
Pingus - Spiel das mit PTC programmiert wurde.
PExL - Extension Library für PTC.
g2 Homepage

Mesa ist eine freie Implementierung des OpenGL-APIs und für eine Vielzahl von Betriebssystemen erhältlich. Außer dem vollständigen API kennt Mesa auch eine ganze Reihe von OpenGL-Extensions. Eine detaillierte Abhandlung des OpenGL-APIs findet sich in dem entsprechenden Artikel aus dieser Vortragsreihe. Die linuxspezifischen Probleme bei der hardwarebeschleunigten Darstellung von OpenGL-Grafik unter XFree finden sich im Abschnitt Direct Rendering Infrastructure (DRI).

Links

OpenGL Homepage
Mesa Homepage
[TODO: Link zum OpenGL-Artikel einfügen]

Bei OSS/Free handelt es sich um eine freie Implementierung des OSS-APIs von 4Front Technologies. Das System ist in der Unix-Welt weit verbreitet und es existieren Treiber für Linux, *BSD, Solaris, UnixWare, AIX und HPUX. Dabei werden auf PC-Architekturen alle gängigen Soundkarten unterstützt. Probleme gibt es nur bei sehr neuen oder sehr speziellen Karten. Aufgrund der guten Portabilität von OSS-Programmen konnte sich das System recht schnell durchsetzen und es existieren mittlerweile eine ganze Reihe von Audioprogrammen, die auf dem OSS-API aufsetzen.

Das OSS-API ist zwar portabel, arbeitet aber trotzdem teilweise direkt auf Systemebene. Das heißt der Programmierer muß selbst ein Audiodevice öffnen und ansprechen. OSS stellt dazu nur die notwendigen Funktionen zur Verfügung ohne den Mechanismus zu abstrahieren.

Liste der unterstützten Features

• Mixer-Steuerung
• digitales Recoding/Playback Interface
• FM/Wavetable Synthese
• MIDI in/out
• Full duplex (*)
• Hardware DSP-Effekte (Reverb, ...) (*)
• 3D Sound (*)

(*) Nicht in OSS/Free enthalten.

Links

OSS Homepage
OSS Dokumentation

ALSA ist das Produkt einer Gruppe von Linux-Hackern und Freeware-Programmierern, die mit OSS/Free nicht völlig zufrieden waren. Ursprünglich ging es den Beteiligten nur darum Treiber für bislang von OSS/Free noch nicht unterstützte Soundkarten zu schreiben. Da OSS den Entwicklern recht undurchsichtig erschien, beschlossen sie auch noch eine völlig neue Bibliothek zu entwickeln. Allerdings ist ALSA eine Linux-spezifische Lösung, das heißt Programme die spezielle ALSA-Features benutzen können nicht ohne weiteres auf andere Systeme portiert werden.

Ein entscheidender Punkt des ALSA-Designs ist die oben abgebildete modulare Struktur. Die saubere Trennung der Programmteile in einzelne Module minimiert vor allem den Arbeitsaufwand beim Schreiben neuer Treiber. Dazu genügt es in der Regel den kartenspezifischen Code (unterste Ebene) zu schreiben. Bereits der Low-Level chipspezifische Code ist für viele Karten identisch. Falls es auf dieser Ebene trotzdem Unterschiede gibt, kann man immerhin davon ausgehen, daß es mehrere Karten gibt, welche die gleichen Chips benutzen. Die OSS-Emulationsschicht ermöglicht es unter ALSA weiterhin alle OSS-Applikationen zu benutzen. Das ist sicherlich einer der Gründe warum ALSA sehr schnell weite Akzeptanz gefunden hat. Die abstrakten Geräteschnittstellen der mittleren Ebene stellen schließlich eine deutliche Verbesserung gegenüber OSS dar. Mittels dieser Architektur kann der Programmierer durch einfaches Linken seiner Anwendung gegen die ALSA-Libraries auf sämtliche Audioschnittstellen zugreifen, ohne sich über deren genaue Eigenschaften (Name, Rechte, Modus) Gedanken machen zu müssen. Das ist eigentlich auch derselbe Ansatz den das GGI-Projekt für Grafik verfolgt.

Links

ALSA Homepage

SDL ist ein sehr einfacher Spiele SDK. Das API gibt dem Programmierer zwar die Möglichkeit auf Low-Level Funktionen des jeweiligen Betriebsssystems zuzugreifen, versucht aber zugleich alle Funktionen auf portable Weise zu abstrahieren. Schließlich wurde SDL gerade zur Portierung von Spielen entwickelt. Aufgrund des Ansatzes ist SDL prinzipiell sehr mächtig, d.h. man kann damit prinzipiell alles implementieren was auf der jeweiligen Plattform möglich ist. Der Nachteil dieses Konzepts ist, daß sich der Programmierer noch um viele Details kümmern muß ("SDL isn't service minded, but gets you as close to the iron as possible."). SDL unterstützt eine ganze Reihe von APIs auf verschiedenen Plattformen, darunter DirectX auf Windows 9x und OpenGL auf Linux. Allerdings kennt SDL in der aktuellen Version keine 3D-Grafikfunktionen. Diese können aber direkt programmiert und eingebunden werden, z.B. als OpenGL-Programm.

SDL wurde vom Chefprogrammierer der Firma Loki Games entwickelt. Lokigames nutzt SDL auch intensiv um aktuelle PC-Spiele, die bislang nur für Microsoft-Betriebssysteme erhältlich waren, auf Linux zu portieren. Zwei aktuelle Spiele, die erst vor kurzem für Linux erschienen sind, sind

• Civilization: Call to Power und
  
• Myth 2
  

Links

Lokigames- Homepage

Bei Crystal Space handelt es sich nicht um einen allgemeinen Game SDK, sondern um die speziellere Variante einer 3D-Engine. Interessant an Crystal Space ist vor allem das fortgeschrittene Stadium des Projekts, das ohne Sponsoring durch eine Firma entwickelt wird. Derzeit gibt es Crystal Space für eine ganze Reihe von Betriebssystemen. Von der folgenden Aufzählung werden allerdings noch nicht alle mit vollem Funktionsumfang unterstützt.

• Linux und diverse UNIXe,
• DOS, Windows, Windows NT,
• OS/2,
• BeOS, NextStep, OpenStep, MacOS/X Server, Amiga und Macintosh

Der Aufbau von Crystal Space gliedert sich wie folgt:

• Mathematical Classes
• General Utility Classes
• 3D Engine
• Physics Engine
• Scripting Engine
• 3D Rasterizer
• 2D Display Driver
• System Dependent Driver
• Sound Drivers
• Crystal Space Application Level

Links

Crystal Space- Homepage

PengiunPlay ist ein Projekt, daß sich als Framework für die diversen APIs und SDKs versteht. Ziel ist es einen allgemeinen Spiele SDK zu entwickeln, der z.B. SDL als API für 2D-Graphik und Crystal Space als 3D-Engine anbietet. Dazu implementiert das Entwicklerteam derzeit eine Reihe von Funktionen, die für eine effiziente und komfortable Programmierung von Spielen wichtig, aber in den existierenden SDKs noch nicht enthalten sind. Derzeit existieren die Module PSound und PFile. PSound ist ein High-Level Sound-API mit Unterstützung für spezielle Effekte. PFile ist ein API für einen effizienten Dateizugriff, auch über Netzwerk.

Weitere Projekte:

• SCITech MGL (kommerziell)
• ClanLib
• GNU Animation and Multimedia Entertainment System (GAMES)

Links

Das Video4Linux-Projekt beschäftigt sich mit der Entwicklung von Treibern für Radio- und TV-Karten. Um diese Karten anzusprechen definiert Video4Linux 4 neue Devices:

Audio,

7. Zusammenfassung

Multimedia unter Linux steckt derzeit leider immer noch in den Kinderschuhen. Allerdings ist der gesamte Bereich derzeit in großer Bewegung und in Anbetracht der Tatsache, daß die bisherige Entwicklung sehr schnell verlaufen ist, darf man schon recht bald größere Fortschritte auf diesem Gebiet erwarten. Mit dem ALSA-Projekt und der Direct Rendering Infrastructure stehen schon bald umfangreiche und sehr effiziente Sound- und Grafik-Architekturen zur Verfügung. Aufgrund des großen Interesses von Seiten der Industrie ist auch zu erwarten, daß künftig viele Hersteller entsprechender Hardware selbst Linux-Treiber für ihre Produkte entwickeln und ausliefern, oder zum Download bereitstellen, werden. Diese Entwicklung wird sicher auch der Spieleindustrie den Weg ebnen, auch Spiele mit aktuellen Hardwareanforderungen auf Linux zu portieren.
Andererseits darf man wohl nicht erwarten, daß Linux in naher Zukunft für alle Anwender eine Alternative zu PCs mit MS Windows darstellen wird. Gerade bei multimedialen Anwendungen, die auch nach ungewöhnlicher Hardware verlangen, benötigt der Anwender derzeit noch Grundkenntnisse mit Unix-Devices und Kernelmodulen.
Allerdings könnte das Interesse der "Power-User" an Linux als Betriebssystem bald schon steigen. Schließich erwarten die Entwickler von den neuen Architekturen einen deutlichen Performancegewinn von Linux gegenüber herkömmlichen "All-in-one" Systemen, da die Modularität und weitgehende Konfigurierbarkeit des Systems bis in den Kernel hinein, eine ganze Reihe von Optimierungen zuläßt.