700 lines
22 KiB
HTML
700 lines
22 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Libraries</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="The Linux Gamers' HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Definitions: Types Of Games"
|
|
HREF="definitions.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="XFree86 and You"
|
|
HREF="x276.html"></HEAD
|
|
><BODY
|
|
CLASS="SECT1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>The Linux Gamers' HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="definitions.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x276.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="AEN130"
|
|
></A
|
|
>3. Libraries</H1
|
|
><P
|
|
>We'll run through the different gaming libraries you'll see under Linux.</P
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="GLIDE2"
|
|
></A
|
|
>3.1. What is Glide2?</H2
|
|
><P
|
|
>Glide2 is a low level graphics API and driver that accesses 3D hardware accelerated
|
|
functions on 3dfx's Voodoo I, II and III cards, under XFree86 3.x.</P
|
|
><P
|
|
>A program can only use the special hardware accelerated features of these cards by using
|
|
the Glide2 library in one of two ways:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>directly written using Glide2 (Myth II, Descent III)</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>indirectly using Mesa built with a Glide2 backend to simulate OpenGL (Rune,
|
|
Unreal Tournament)</P
|
|
></LI
|
|
></UL
|
|
><P
|
|
>3dfx opened up the specifications and source code to the open source community. This
|
|
allowed Daryll Strauss to port Glide2 to Linux which enabled XFree86 3.x users to use Voodoo
|
|
I, II and III cards under Linux.</P
|
|
><P
|
|
>Since Glide2 accesses the video card directly, Glide2 applications will either need to
|
|
be run by root or be setuid root. A way around this was to create the kernel 3dfx module.
|
|
This module (and its device file <TT
|
|
CLASS="FILENAME"
|
|
>/dev/3dfx</TT
|
|
>) allows Glide2 graphical
|
|
hardware acceleration for non-root users of non-setuid applications.</P
|
|
><P
|
|
>Unfortunately, Glide2 is also a dead issue. It's only used for Voodoo I, II, III boards
|
|
(which are becoming outdated), under XFree86 3.x (most people use XFree86 4.x). And since
|
|
3dfx is now a defunct company, it's a sure bet that no more work will be done on Glide2 and no
|
|
more games will be written using Glide2.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="GLIDE3"
|
|
></A
|
|
>3.2. What is Glide3?</H2
|
|
><P
|
|
>Unlike Glide2, Glide3 is not an API used for game programming. It exists only to
|
|
support DRI on Voodoo III, IV and V boards under XFree86 4.x. None of the games which use
|
|
Glide2 will work with Glide3. This shouldn't be a surprise since Glide2 and Glide3 support
|
|
different video cards and different versions of XFree86. The only video card that can use
|
|
both Glide2 (under XFree86 3.x) and Glide3 (under XFree86 4.x) is the Voodoo III. It's
|
|
reported that a Voodoo III using Glide2 will outperform a Voodoo III using Glide3.</P
|
|
><P
|
|
>When you use a Voodoo III, IV or V under XFree86 4.x, you want to use a version of Mesa
|
|
(see <A
|
|
HREF="x130.html#MESA"
|
|
>Section 3.4</A
|
|
>) which was compiled to use Glide3 as a backend to ensure hardware
|
|
accelerated OpenGL on your system.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="OPENGL"
|
|
></A
|
|
>3.3. What is OpenGL?</H2
|
|
><P
|
|
>OpenGL is a high level graphics programming API originally developed by SGI, and it
|
|
became an industry standard for 2D and 3D graphics programming. It's defined and maintained
|
|
by the Architectural Revision Board (ARB), an organization which include representatives from
|
|
SGI, IBM, DEC, and Microsoft. OpenGL provides a powerful, complete and generic feature set
|
|
for 2D and 3D graphics operations.</P
|
|
><P
|
|
>There are 3 canonical parts to OpenGL:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>GL: The OpenGL core calls</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>GLU: The utility calls</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>GLUT: OS independent window event (mouse, keyboard, etc.)
|
|
handler.</P
|
|
></LI
|
|
></UL
|
|
><P
|
|
>OpenGL is not only an API, it's also an implementation, written by SGI. The
|
|
implementation tries to use hardware acceleration for various graphics operations whenever
|
|
available, which depends on what videocard you have in you computer. If hardware acceleration
|
|
is not possible for a specific task, OpenGL falls back on software rendering. This means that
|
|
when you get OpenGL from SGI, if you want any kind of hardware acceleration at all, it must be
|
|
OpenGL written and compiled specifically for some graphics card. Otherwise, all you'll get is
|
|
software rendering. The same thing is true for OpenGL clones, like Mesa.</P
|
|
><P
|
|
>OpenGL is the open source equivalent to Direct3D, a component of DirectX (<A
|
|
HREF="x130.html#DIRECTX"
|
|
>Section 3.14</A
|
|
>). The important difference being that since OpenGL is open (and DirectX is
|
|
closed), games written in OpenGL are much easier to port to and co-develop on Linux than games
|
|
written using DirectX.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="MESA"
|
|
></A
|
|
>3.4. What is Mesa?</H2
|
|
><P
|
|
>Mesa <<A
|
|
HREF="http://www.mesa3d.org"
|
|
TARGET="_top"
|
|
>http://www.mesa3d.org</A
|
|
>> is a free implementation of the
|
|
OpenGL API, designed and written by Brian Paul. While it's not officially certified (that
|
|
would take more money than an open source project has), it's an almost fully compliant OpenGL
|
|
implementation conforming to the ARB specifications. It's reported that Mesa is even faster
|
|
than SGI's own OpenGL implementation.</P
|
|
><P
|
|
>Just like OpenGL, Mesa makes use of hardware acceleration whenever possible. When a
|
|
particular graphics task isn't able to be hardware accelerated by the video card, it's
|
|
software rendered; the task is done by your computer's CPU instead. This means that there are
|
|
different builds of Mesa depending on what kind of video card you have. Each build uses a
|
|
different library as a backend renderer. For example, if you have a Voodoo I, II or III card
|
|
under XFree86 3.x, you'd use mesa+glide2 (written by David Bucciarelli) which is the Mesa
|
|
implementation of OpenGL that uses Glide2 as a backend to render for graphical
|
|
operations.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN170"
|
|
></A
|
|
>3.5. What is DRI?</H2
|
|
><P
|
|
>Graphics rendering has 3 players: the client application (like Quake 3), the X server
|
|
and the hardware (the graphics card). Previously, client applications were prohibited from
|
|
writing directly to hardware, and there was a good reason for this. A program that is allowed
|
|
to directly write to hardware can crash the system in any number of ways. Rather than
|
|
trusting programmers to write totally bug free, cooperative programs that access hardware,
|
|
Linux simply disallowed it. However, that changed under X 4.x with DRI (Direct Rendering
|
|
Infrastructure <<A
|
|
HREF="http://www.dri.sourceforge.net"
|
|
TARGET="_top"
|
|
>http://www.dri.sourceforge.net</A
|
|
>>. DRI allows X
|
|
clients to write 3D rendering information directly to the video card in a safe and cooperative
|
|
manner.</P
|
|
><P
|
|
>DRI gets the X server out of the way so the 3D driver (Mesa or OpenGL) can talk directly
|
|
to the hardware. This speeds things up. The 3D rendering information doesn't even have to be
|
|
hardware accelerated. On a technical note, this has a number of virtues.</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>Vertex data doesn't have to be encoded/decoded via GLX.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Graphics data isn't sent over a socket to the X server.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>On uni-processor machines the CPU doesn't have to change context between
|
|
XFree86 and its client to render the graphics.</P
|
|
></LI
|
|
></UL
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN182"
|
|
></A
|
|
>3.6. What is GLX?</H2
|
|
><P
|
|
>GLX is the X extension used by OpenGL programs, it is the glue between the platform
|
|
independent OpenGL and platform dependent X.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN185"
|
|
></A
|
|
>3.7. What is Utah GLX?</H2
|
|
><P
|
|
>Utah-GLX is the precursor to DRI. It makes some different design decisions regarding
|
|
separation of data and methods of accessing the video card like relying on root access rather
|
|
than creating the kernel infrastructure for secure access. It provides support for a few
|
|
cards which are not well supported by DRI like the ATI Rage Pro family, S3 Virge (although
|
|
anyone using this for gaming is, well, nuts), and an open source TNT/TNT2 driver (which is
|
|
very incomplete). The TNT/TNT2 driver is based on reverse-engineering of the obfuscated
|
|
source code release of the X 3.3 drivers by nVidia. However, they're really incomplete, and
|
|
effectively, unusable.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="XLIB"
|
|
></A
|
|
>3.8. What is xlib?</H2
|
|
><P
|
|
>Every once in awhile you'll see some sicko (said with respect) write a game in xlib. It
|
|
is a set of C libraries which comprise the lowest level programming interface for XFree86.
|
|
Any graphics programming in X ultimately makes use of the xlib library.</P
|
|
><P
|
|
>It's not an understatement to say that xlib is long winded, arcane and complicated.
|
|
Because of this, there are lots of libraries like SDL (<A
|
|
HREF="x130.html#SDL"
|
|
>Section 3.10</A
|
|
>) for 2D graphics,
|
|
OpenGL (<A
|
|
HREF="x130.html#OPENGL"
|
|
>Section 3.3</A
|
|
>) for 3D graphics and widget sets (<A
|
|
HREF="x130.html#WIDGETSET"
|
|
>Section 3.9</A
|
|
>)
|
|
for widgets within windows which hide the details of different aspects of xlib
|
|
programming.</P
|
|
><P
|
|
>While some games are written in xlib, like the Doom Editor Yadex, xlib itself is not a
|
|
serious game writing library. Most games don't need the low-level interface that xlib
|
|
provides. In addition, by using the higher level libraries, a game writer can develop his
|
|
game on multiple platforms, even ones that don't use XFree86.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="WIDGETSET"
|
|
></A
|
|
>3.9. What is a widget set?</H2
|
|
><P
|
|
>Widgets are objects that make up a GUI application's interface. They include things
|
|
like text entry boxes, pulldown menus, slider bars, radio buttons and much more. A widget set
|
|
is a collection of related widgets that are designed to have a common interface and a
|
|
consistant "feel". Gtk is the canonical widget set on Linux, but there are many others like
|
|
fltk (a small C++ widget set), Xaw, Qt (the widget set of KDE), and Motif (the widget set used
|
|
by Netscape). Motif used to be the king of widget sets in the Unix world, but it was very
|
|
expensive to license. The Open Group finally opened up Motif's license for open source
|
|
operating systems, but it was too little too late. There are many completely open source
|
|
widget sets which are more complete and much nicer looking than Motif, including Lesstif, a
|
|
totally free Motif clone.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="SDL"
|
|
></A
|
|
>3.10. What is SDL (Simple DirectMedia Layer)?</H2
|
|
><P
|
|
>SDL <<A
|
|
HREF="http://www.libsdl.org"
|
|
TARGET="_top"
|
|
>http://www.libsdl.org</A
|
|
>> is a library by Sam Lantiga
|
|
(graduate of UCD, yeah!). It's actually a meta-library, meaning that not only is it a
|
|
graphics library which hides the details of xlib programming, it provides an easy interface
|
|
for sound, music and event handling. It's LGPL'd and provides joystick and OpenGL support as
|
|
well. Unlike xlib (<A
|
|
HREF="x130.html#XLIB"
|
|
>Section 3.8</A
|
|
>), SDL is very suited for game programming.</P
|
|
><P
|
|
>The most striking part of SDL is that it's a cross platform library. Except for a few
|
|
details, a program written in SDL will compile under Linux, MS Windows, BeOS, MacOS, MacOS X,
|
|
Solaris, IRIX, FreeBSD, QNX and OSF. There are SDL extensions written by various people to do
|
|
things like handle any graphics format you care to mention, play mpegs, display truetype
|
|
fonts, sprite handling and just about everything under the sun. SDL is an example of what all
|
|
graphics libraries should strive for.</P
|
|
><P
|
|
>Sam had an ulterior motive for writing such a cool library. He was the lead programmer
|
|
for Loki Software (he now codes for Blizzard Software), which used SDL in all of its games
|
|
except for Quake3.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="GGI"
|
|
></A
|
|
>3.11. What is GGI?</H2
|
|
><P
|
|
>GGI <<A
|
|
HREF="http://www.ggi-project.org"
|
|
TARGET="_top"
|
|
>http://www.ggi-project.org</A
|
|
>> is a project which aims to
|
|
implement a graphics abstraction layer in lower level code, put graphics hardware support into
|
|
a common codebase, and bring higher stability and portability to graphics applications.
|
|
LibGGI applications run on SVGAlib, fb, and X servers among others. Judging from their
|
|
screenshots, this is quite a powerful library.</P
|
|
><P
|
|
>Applications that use LibGGI directly include Heroes, Ultrapoint, Quake, and Berlin.
|
|
Most applications that use SVGALib can be run on X or any other LibGGI backend by using a
|
|
wrapper library which re-implements SVGALib (<A
|
|
HREF="x130.html#SVGALIB"
|
|
>Section 3.12</A
|
|
>) using LibGGI. SDL
|
|
(<A
|
|
HREF="x130.html#SDL"
|
|
>Section 3.10</A
|
|
>) and clanlib (<A
|
|
HREF="x130.html#CLANLIB"
|
|
>Section 3.15</A
|
|
>) applications can display on
|
|
LibGGI but often the native drivers for these libraries are faster, however it's a good way to
|
|
get SDL, clanlib, and SVGALib applications to run where they would not before.</P
|
|
><P
|
|
>GGI has a sister project, KGI, which is developing a kernel-level alternative to systems
|
|
like the linux framebuffer and the DRI. This project is much less far along than LibGGI
|
|
itself, but promises to combine DRI-level speeds and the stability and security UNIX users
|
|
expect.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="SVGALIB"
|
|
></A
|
|
>3.12. What is SVGAlib? Frame buffer? Console?</H2
|
|
><P
|
|
>The console is the dark non-graphical screen you look at when your computer first boots
|
|
up (and you don't have <SPAN
|
|
CLASS="APPLICATION"
|
|
>xdm</SPAN
|
|
> or <SPAN
|
|
CLASS="APPLICATION"
|
|
>gdm</SPAN
|
|
>
|
|
running). This is opposed to the X environment which has all sorts of GUI things like xterms.
|
|
It's a common misconception that X means graphics and console means no graphics. There are
|
|
certainly graphics on the console—we will discuss the two most common ways to achieve
|
|
this.</P
|
|
><P
|
|
>SVGAlib is a graphics library that lets you draw graphics on the console. There are
|
|
many graphical applications and games that use SVGAlib like <SPAN
|
|
CLASS="APPLICATION"
|
|
>zgv</SPAN
|
|
> (a
|
|
console graphical image viewer), <SPAN
|
|
CLASS="APPLICATION"
|
|
>prboom</SPAN
|
|
> and
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>hhexen</SPAN
|
|
>. I happen to be a fan of this library and of graphical
|
|
console games in general; they are extremely fast, fullscreen and compelling. There are three
|
|
downsides to SVGAlib. First, SVGAlib executables need to be run by root or be setuid root,
|
|
however, the library releases root status immediately after the executable begins to run.
|
|
Secondly, SVGAlib is video card dependent–if your video card isn't supported by SVGAlib,
|
|
you're out of luck. Third, SVGAlib is Linux only. Games written in SVGAlib will only work on
|
|
Linux.</P
|
|
><P
|
|
>Frame buffers are consoles implemented by a graphics mode rather than a BIOS text mode.
|
|
Why simulate text mode in a graphical environment? This allows us to run graphical things in
|
|
console, like allowing us to choose any font we want the console to display (which is normally
|
|
set by BIOS). There's a good Framebuffer HOWTO available from LDP. Graphical console games
|
|
written using the frame buffer suffer from the same deficiencies of the SVGA library: not all
|
|
hardware is supported and the code will only run on Linux.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="OPENAL"
|
|
></A
|
|
>3.13. What is OpenAL?</H2
|
|
><P
|
|
>OpenAL <<A
|
|
HREF="http://www.openal.org"
|
|
TARGET="_top"
|
|
>http://www.openal.org</A
|
|
>> aims to be for sound what
|
|
OpenGL is for graphics. It started as a joint project between Loki Software and Creative
|
|
Labs, setting out to be a vendor neutral and cross platform API for audio - the audio
|
|
equivalent of OpenGL (<A
|
|
HREF="x130.html#OPENGL"
|
|
>Section 3.3</A
|
|
>). Loki is no longer in business, but Creative
|
|
and the Open Source community have kept the project alive. It is licensed LGPL and the specs
|
|
can be obtained for free from the OpenAL website. It has support from nVidia (nForce2/3 based
|
|
motherboards come with OpenAL MS Windows libraries for the on-board audio), Apple has added
|
|
OpenAL to their audio framework for OSX and it can also be found powering the Epic Games
|
|
Unreal Engine</P
|
|
><P
|
|
>Currently, it's not all cross-platform goodness. There is almost no support for
|
|
enhancements like EAX or any hardware acceleration on Linux, though it does it exist in the
|
|
Windows implementation. However, if you have a Creative SoundBlaster or Audigy sound card
|
|
(with an emu10x chip), and you use ALSA sound drivers, you can get OpenAL libraries from
|
|
<A
|
|
HREF="http://www.lost.org.uk"
|
|
TARGET="_top"
|
|
>http://www.lost.org.uk</A
|
|
> that provide hardware acceleration and decent
|
|
surround support.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="DIRECTX"
|
|
></A
|
|
>3.14. What is DirectX?</H2
|
|
><P
|
|
>DirectX is a collection of proprietary multimedia API's, first developed by Microsoft in
|
|
1995, for its various Windows OS's. It's a mistake to say something like "DirectX is like
|
|
OpenGL" or "DirectX is like SDL", as is commonly said in DirectX tutorials. Multimedia API's
|
|
are more centralized on Windows than they are on Linux. A more accurate statement would be
|
|
something like "DirectX is like DRI, OpenGL and SDL combined". As of October 2004, the most
|
|
recent version of DirectX is 9c. The components of DirectX are:</P
|
|
><P
|
|
></P
|
|
><DIV
|
|
CLASS="VARIABLELIST"
|
|
><DL
|
|
><DT
|
|
>DirectDraw</DT
|
|
><DD
|
|
><P
|
|
>DirectDraw gives direct access to video memory, like DRI, so 2D graphics can
|
|
be blitted directly to the video card. DirectDraw is like the graphical component of SDL,
|
|
but the direct video card access is done by DRI rather than SDL. This is why a game can
|
|
easily take out a Windows system but should not take down a Linux
|
|
system.</P
|
|
></DD
|
|
><DT
|
|
>Direct3D (D3D)</DT
|
|
><DD
|
|
><P
|
|
>Direct3D, like OpenGL, provides a 3D graphics API. Whereas OpenGL is open
|
|
source, lower level and compiles under a multitude of operating systems, D3D is proprietary,
|
|
higher level and only compiles on Windows. D3D first appeared in DirectX 2, released in
|
|
1996.</P
|
|
></DD
|
|
><DT
|
|
>DirectAudio</DT
|
|
><DD
|
|
><P
|
|
>DirectAudio is a combination of 2 audio API's, DirectSound and DirectMusic,
|
|
which allows direct access to the sound card for sound and music
|
|
playback.</P
|
|
></DD
|
|
><DT
|
|
>DirectInput</DT
|
|
><DD
|
|
><P
|
|
>DirectInput gives support for gaming input devices such as
|
|
joysticks.</P
|
|
></DD
|
|
><DT
|
|
>DirectPlay</DT
|
|
><DD
|
|
><P
|
|
>DirectPlay gives support for simplified networking for multiplayer
|
|
gaming.</P
|
|
></DD
|
|
><DT
|
|
>DirectShow</DT
|
|
><DD
|
|
><P
|
|
>DirectShow provides support for movie files like AVI and MPG. It was a
|
|
separate API from DirectX, but was integrated with DirectX
|
|
8.</P
|
|
></DD
|
|
><DT
|
|
>DirectSetup</DT
|
|
><DD
|
|
><P
|
|
>This API provides a way to install DirectX from within an application to
|
|
simplify game installation.</P
|
|
></DD
|
|
></DL
|
|
></DIV
|
|
><P
|
|
>Depending on the version of DirectX you're talking about, DirectX support in winex
|
|
(<A
|
|
HREF="x809.html#WINEX"
|
|
>Section 10.5.3</A
|
|
>) ranges from well supported to "kind of" supported. It's poorly
|
|
supported by wine (<A
|
|
HREF="x809.html#WINE"
|
|
>Section 10.5.1</A
|
|
>), barely supported by vmware (<A
|
|
HREF="x809.html#VMWARE"
|
|
>Section 10.5.5</A
|
|
>) and unsupported by Win4Lin (<A
|
|
HREF="x809.html#WIN4LIN"
|
|
>Section 10.5.4</A
|
|
>).</P
|
|
><P
|
|
>One comment about portability: Each component of DirectX has multiple corresponding
|
|
library on Linux. Moreover, a game writer who uses libraries like OpenGL, GGI or SDL will
|
|
write a game which will trivially compile on Windows, Linux and a multitude of other OS's.
|
|
Yet game companies persist using DirectX and therefore limit their audience to Windows users
|
|
only. If you're a game writer, please consider using cross platform libraries and stay away
|
|
from DirectX.</P
|
|
><P
|
|
>A company named realtechVR started an open source project, DirectX Port, <<A
|
|
HREF="http://www.v3x.net/directx"
|
|
TARGET="_top"
|
|
>http://www.v3x.net/directx</A
|
|
>> which, like wine, provides a Direct3D emulation
|
|
layer that implements Direct3D calls. The project was focused on the BeOS platform, but is
|
|
now focused on MacOS and Linux. You can get the latest cvs from their sourceforge page at
|
|
<<A
|
|
HREF="http://sourceforge.net/projects/dxglwrap"
|
|
TARGET="_top"
|
|
>http://sourceforge.net/projects/dxglwrap</A
|
|
>>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="CLANLIB"
|
|
></A
|
|
>3.15. Clanlib</H2
|
|
><P
|
|
>ClanLib is a medium level development kit. At its lowest level, it provides a platform
|
|
independent (as much as that is possible in C++) way of dealing with display, sound, input,
|
|
networking, files, threading and such. ClanLib builds a generic game development framework,
|
|
giving you easy handling of resources, network object replication, graphical user interfaces
|
|
(GUI) with theme support, game scripting and more.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="definitions.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x276.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Definitions: Types Of Games</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>XFree86 and You</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |