Una limitazione che ha frenato l'uso di Linux sul desktop è stata la carenza di supporto 3D su XFree86, l'X Window Server opensource utilizzato in tutte le distribuzioni.
Per godere della accelerazione hardware 3D delle schede di Nvidia (GeForce, TNT, Quadro) si possono scaricare i driver Linux ufficiali da www.nvidia.com, che dalla versione 1.0-4349 prevedono un nuovo comodo ed efficace meccanismo di installazione che, soprattutto se si utilizzano i kernel ufficiali di distribuzioni come RedHat, Mandrake, Suse, è piuttosto semplice e regala in fretta le ovvie soddisfazioni sia per il supporto accellerato OpenGL che per la gestione dell'output su TV, su schermi flat e anche di due schermi contemporaneamente, se supportato dalla propria scheda Nvidia.
Vediamo come procedere per installare i driver Nvidia:
[al@localhost DOWN]$ wget http://download.nvidia.com/XFree86/Linux-x86/1.0-4349/NVIDIA-Linux-x86-1.0-4349.run
[al@localhost DOWN]$ ls -la
-rw------- 1 al al 6483213 Apr 18 21:11 NVIDIA-Linux-x86-1.0-4349.run
[al@localhost DOWN]$ chmod 755 NVIDIA-Linux-x86-1.0-4349.run
Il file scaricato è un binario autoinstallante, deve essere eseguibile
[al@localhost DOWN]$ ./NVIDIA-Linux-x86-1.0-4349.run
Verifying archive integrity... OK
Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86 1.0-4349........................
nvidia-installer: Error opening log file '/var/log/nvidia-installer.log' for writing (Permission denied); disabling logging.
[al@localhost DOWN]$ su
Solo root può installare un nuovo modulo per il kernel
Password:
[root@localhost DOWN]# ./NVIDIA-Linux-x86-1.0-4349.run
Verifying archive integrity... OK
Appare una finestra con licenza d'uso da accettare e indicazioni su cosa viene installato e come completare la configurazione. Il programma di installazione provvede anche a scaricare, ne necessario, gli aggiornamenti del driver e il supporto per nuove versioni del kernel per le principali distribuzioni.
I requisiti di base sono:
- linux kernel 2.2.12 # cat /proc/version
- XFree86 4.0.1 # XFree86 -version
- Kernel modutils 2.1.121 # insmod -V
Installati i binari si deve procedere alla configurazione di XF86config.
[root@localhost al]# vi /etc/X11/XF86Config
Qui fondamentalmente, per una installazione base, basta sostituire nella Device Section:
Driver "nv"
(o Driver "vesa")
con
Driver "nvidia"
assicurarsi che esista nella Module Section:
Load "glx"
e siano commentate o assenti le seguenti righe:
## Load "dri"
## Load "GLcore"
Per andare oltre queste indicazioni essenziali e in caso di problemi esiste un ottimo README:
[root@localhost DOWN]# cat /usr/share/doc/NVIDIA_GLX-1.0/README
Prima di riavviare il proprio X Server occorre essere consapevoli che qualcosa può fallire (driver inadatti al proprio kernel, configurazione di XFree sbagliata, Murphy vari...) e quindi essere pronti e in grado di ripristinare un sistema che reebootta in modalità grafica (init 5) e non riesce ad aprire l'X Window accellerato, balendando cambi di risoluzione sul monitor e fallendo con messaggio di errore tipo: Respawning too fast.
In questi casi, dalla modalità testale (init 3) consultare il README e guardare il log (/var/log/XFree86.0.log).
Per procedere si deve uscire dalla eventuale propria sessione grafica corrente:
[root@localhost DOWN]# init 3
.
Eseguire un login da console (sempre meglio evitare di usare l'utente root, soprattutto se si usa X Windows):
[al@localhost DOWN]> startx
e se gli astri ci sono favorevoli, o semplicemente abbiamo seguito le istruzioni, appare il logo Nvidia e il nostro Desktop accellerato si apre pronto per essere studiato.
Chi vuole approfondire è possibile provare le opzioni del file scaricato:
./NVIDIA-Linux-x86-1.0-4349.run --help
- Elenca le opzioni disponibili
./NVIDIA-Linux-x86-1.0-4349.run --info
- Mostra informazioni sulla versione del driver e la directory di installazione
./NVIDIA-Linux-x86-1.0-4349.run --update
- Scarica da Internet e installa i driver aggiornati
./NVIDIA-Linux-x86-1.0-4349.run --uninstall
- Disinstalla i driver.
./NVIDIA-Linux-x86-1.0-4349.run --extract-only
- Non installa niente e scompatta tutto in una directory dove si trovano file fondamentali per approfondire:
.nvidia-installer
- I programma di installazione, con le stesse opzioni del pacchetto .run
./usr/share/doc/XF86Config.sample
- File di conf di XFree con esempi utili per il supporto TwinView e altre modalità a doppio schermo.
./usr/share/doc/README
- Readme completo, con varie informazioni e appendici per il tuning della configurazione di X Windows e il troubleshooting.
Sul sistema vengono installati vari componenti chiave:
/usr/X11R6/lib/modules/drivers/nvidia_drv.o
- Il driver per XFree86 (4.0.1 o superiore).
/usr/X11R6/lib/modules/extensions/libglx.so.x.y.z
- Il modulo per il supporto di GLX (Specifiche di Silicon Graphics per l'uso di OpenGL su XWindow)
/usr/lib/libGL.so.x.y.z
- Libreria condivisa per l'accesso alle funzioni OpenGL e GLX, viene caricata dinamicamente dalle applicazioni OpenGL
/lib/modules/`uname -r`/video/nvidia.o
o /lib/modules/`uname -r`/kernel/drivers/video/nvidia.o
Il modulo per il kernel che permette l'accesso a basso livello sull'hardware Nvidia. Viene caricato dal kernel quando si avvia X. Consta di due componenti: il core, di cui Nvidia distribuisce soltanto il binario e una kernel interface che è strettamente dipendente dalla versione del proprio kernel.
Se si aggiorna il proprio kernel tramite un pacchetto ufficiale, è necessario reinstallare i driver Nvidia (la parte di kernel interface del modulo è strettamente vincolata allo specifico kernel installato). La procedura è rapida ed indolore, i driver scaricati possono autoaggiornarsi e provvedere, generalmente senza intoppi (se si usano le distribuzioni supportate da Nvidia) a ripristinare il supporto 3d su XWindow:
[root@localhost DOWN]# ./NVIDIA-Linux-x86-1.0-4349.run
Testare le potenzialità di un 3d su Linux
Una volta avviato XServer con i driver Nvidia tutto apparentemente resta uguale, si devono cercare applicazioni, giochi, demo che sfruttino il 3d.
Su molte distribuzioni è disponibile TuxRacer, un gioco dove si lancia un pinguino giù per piste innevate a raccattar bandiere. Vederlo senza accelerazione 3d è scoraggiante, ma con i nuovi driver rivela una fluidità e una giocabilità piacevoli.
Ma questo è solo l'inizio, chi ha comprato Unreal Tournament 2003 per Windows ha la gradita sorpresa di trovare nel terzo CD l'installer per Linux e potrà avere le prestazioni che la sua scheda grafica gli permettono.
Discorso analogo per Quake e un crescente numero di altri giochi.
Altra ottima via per godere di un 3d spettacolare, senza necessariamente avere un gioco comemrciale, è lanciarsi nella ancora acerba ma promettente scena demo su Linux.
Un demo è una sorta di videoclip calcolato in tempo teale, prodotto per svago e senza lucro da gruppi di artisti del computer: grafici, musicisti e programmatori in grado di esprimere emozioni e tecnica tramite il mezzo digitale.
Una ottima conversione per Linux di un demo uscito per Windows nel 2000 è Vip2 (http://www.sesse.net/vip2-linux/)
Come installare e configurare il proprio Joystick in Linux
In Linux il device joystick è presente nella directory di sistema /dev
e precisamente è rappresentato dai seguenti file:
/dev/js0
/dev/js1
/dev/js2
/dev/js3
Ognuno di questi file rappresenta un singolo dispositivo e quindi abbiamo la possibilità di avere 4 joystick contemporaneamente anche se in realtà questa situazione non si verifica mai.
Prima di procedere all'installazione si devono creare manualmente, a meno che non siano già presenti, i seguenti nodes nella directory /dev/input
:
[root@Apollo13 /]# cd /dev
Rimuove i file device attuali
[root@Apollo13 /]# rm js0
[root@Apollo13 /]# rm js1
[root@Apollo13 /]# rm js2
[root@Apollo13 /]# rm js3
[root@Apollo13 /]# mkdir input
Crea i nodes
[root@Apollo13 /]# mknod input/js0 c 13 0
[root@Apollo13 /]# mknod input/js1 c 13 1
[root@Apollo13 /]# mknod input/js2 c 13 2
[root@Apollo13 /]# mknod input/js3 c 13 3
Link a nuovi file device
[root@Apollo13 /]# ln -s input/js0 js0
[root@Apollo13 /]# ln -s input/js1 js1
[root@Apollo13 /]# ln -s input/js2 js2
[root@Apollo13 /]# ln -s input/js3 js3
Per poter utilizzare il joystick è necessario il modulo joydev, inoltre in base alle caratteristiche del nostro dispostivo si rivelano indispensabili altri moduli:
ns558 : se il nostro joystick comunica tramite la gameport
serport: se il nostro joystick comunica attraverso la porta seriale
analog : se il si si tratta di un dispositivo analogico (la maggior parte)
Nel caso che questi moduli non siano stati compilati con il kernel è necessario caricarli.
Poniamo di dover installare un joystick analogico che utilizza la gameport:
[root@Apollo13 /]# modprobe joydev
[root@Apollo13 /]# modprobe ns558
[root@Apollo13 /]# modprobe analog
A questo punto si può testare il funzionamento del joystick tramite l'utility jstest
[root@Apollo13 /]# jstest /dev/js0
jstest visualizza il tipo di joystick collegato, il numero di assi, di pulsanti e la versione del driver
Joystick (Analog 2-axis 4-button joystick) has 2 axes and 4 buttons. Driver version is 2.1.0.
Testing ... (interrupt to exit)
I valori degli assi e lo stato dei pulsanti
Axes: 0: 0 1: 0 Buttons: 0:off 1:off 2:off 3:off
Muovendo il joystick l'utility visualizzerà i valori in input. Se l'utility restituisce No such device, oppure se i valori non cambiano significa che il joystick non è riconosciuto o molto più probabilmente abbiamo commesso qualche errore nella procedura di installazione.
Normalmente il tipo di joystick viene riconosciuto automaticamente da Linux ma se il dispositivo presenta caratteristiche diverse da quelle rilevate da jstest, per esempio ha più assi o più pulsanti, è possibile caricare il modulo analog con il parametro
js=type0,type1,type2,type3
dove type0 è il tipo di joystick rappresentato da js0, type1 è il tipo di joystick rappresentato da js1 e così via...
I valori che può assumere type sono:
none Nessun dispositivo collegato
auto : Rileva automaticamente il joystick (opzione di default)
2btn : 2-Pulsanti n-Assi
y-joy : 2-Pulsanti 2-Assi
y-pad : 2-Pulsanti 2-Assi gamepads
fcs : Thrustmaster FCS joystick
chf : Joystick con un CH Flightstick Hat Switch (pulsante speciale)
fullchf : CH Flightstick con 2 Hat Switch e 6 Pulsanti
gamepad : 4/6-Pulsanti n-Assi gamepad
gamepad8 : 8-Pulsanti 2-Assi gamepad
Per esempio il comando:
[root@Apollo13 /]# modprobe analog js=fcs,none,none,none
specifica un joystick Thrustmaster FCS per js0, nessun joystick per gli altri device.
Se il joystick si discosta ancora da questi tipi standard è possibile utilizzare un tipo personalizzato di type, costruendo un numero in base alle caratteristiche della periferica e alla seguente tabella:
Bit Descrizione
0 : Axis X1
1 : Axis Y1
2 : Axis X2
3 : Axis Y2
4 : Button A
5 : Button B
6 : Button C
7 : Button D
8 : CHF Buttons X and Y
9 : CHF Hat 1
10 : CHF Hat 2
11 : FCS Hat
12 : Pad Button X
13 : Pad Button Y
14 : Pad Button U
15 : Pad Button V
16 : Saitek F1-F4 Buttons
17 : Saitek Digital Mode
19 : GamePad
20 : Joy2 Axis X1
21 : Joy2 Axis Y1
22 : Joy2 Axis X2
23 : Joy2 Axis Y2
24 : Joy2 Button A
25 : Joy2 Button B
26 : Joy2 Button C
27 : Joy2 Button D
31 : Joy2 GamePad
Se per esempio il nostro joystick dispone di 2 assi (X,Y), 3 pulsanti e un FCS Hat:
type = 2^0 + 2^1 + 2^4 + 2^5 + 2^6 + 2^11
type = 2163
[root@Apollo13 /]# modprobe analog js=2163,none,none,none
Ora abbiamo forzato Linux a riconoscere il nostro joystick, non ci resta che verificare
il funzionamento della nuova configurazione eseguendo di nuovo jstest.
In caso di ulteriori problemi, o per controllare se una determinata periferica è supportata dai driver di Linux, è utile leggere il file joystick.txt che solitamente è presente in /usr/share/doc
.
Cos'è OpenGL?
OpenGL (Open Graphics Library) è una potente libreria grafica che si pone il compito di interfacciarsi con l'hardware e fornire al programma client una serie di primitive, più o meno essenziali, per lo sviluppo di applicazioni nel campo del rendering tridimensionale. Queste primitive comprendono funzioni per la manipolazione dei pixel, per la proiezione di poligoni in 3D e per la gestione del movimento degli stessi, per la rappresentazione di luci e colori, per il texture mapping etc.
Il prefisso Open sta ad indicare che OpenGL è una architettura aperta, ciò significa che il suo sviluppo è curato non da una singola azienda ma da una associazione di industrie leader del settore (ATI, Compaq, IBM, nVidia, Hewlett-Packard, Silicon Graphics) che hanno dato vita all'ARB (OpenGL Architecture Review Board).
Questa organizzazione, nata nel 1992, ha il compito di sviluppare e standardizzare gli aggiornamenti di OpenGL, che oggi è giunta alla versione 1.5 (anche se in realtà la versione più diffusa è la 1.1).
Una delle peculiarità di OpenGL che la distingue immediatamente dalle sue rivali (ad esempio DirectX di Microsoft) è la portabilità. Infatti OGL è disponibile su tutte le piattaforme più diffuse, Unix, Linux, Windows, Mac, Solaris etc.
Questa estrema portabilità ha fatto si che anche i costruttori di hardware (nVidia per prima) si adeguassero ad essa e ora un gran numero di schede video moderne hanno la possibilità di eseguire la maggior parte delle funzioni OpenGL direttamente in hardware con un netto vantaggio in termini di prestazioni.
OGL è oggi una delle più valide e potenti librerie grafiche disponibili e lo dimostra il fatto che grandi Software House specializzate nel campo dei videogames l'hanno scelta per sviluppare i propri prodotti. Tra i titoli targati OpenGL troviamo Quake2, Quake3 e (di prossima uscita) Doom III della ID Software, Unreal Tournament 1 e 2 della Epic Games, oppure il mitico Half Life e tanti altri.
Ciò che è importante capire è che OGL e sostanzialmente una libreria grafica di basso livello e le sue funzioni sono relative all'utilizzo delle primitive fondamentali quali vertici e poligoni piuttosto che a modelli complessi la cui gestione viene di norma lasciata nelle mani del programmatore, garantendo così la massima flessibilità.
Naturalmente non mancano le possibilità di creare luci, trasparenze, riflessi e altri "effetti speciali" per trasformare una sterile rappresentazione di poligoni in una affascinante riproduzione della realtà.
OpenGL, nelle sue distribuzioni, è sempre accompagnata dalla libreria GLU (GL Utility Library).
GLU è una libreria ausiliaria che contiene alcuni funzioni di più alto livello, utili ad esempio per la creazione di sfere o altri oggetti complessi ma anche per impostare particolari matrici di proiezione e per facilitare alcune operazioni al programma client. Normalmente, infatti, le funzioni della GLU contengono al loro interno routine basate sulle funzioni base di OGL.
Un'ulteriore libreria che è possibile scaricare (non è fornita di default) è la GLUT (GL Utility Toolkit), si tratta di un toolkit per la creazione delle finestre indipendente dal sistema operativo che permette, utilizzando solamente le funzioni di tale libreria, di scrivere programmi completi nascondendo le differenze di implementazione tra i gestori finestre dei vari sistemi operativi.
In realtà la libreria GLUT, per motivi di prestazioni e di qualità, viene poco utilizzata nelle applicazioni professionali che generalmente si occupano autonomamente di gestire la creazione delle finestre e l'acquisizione dell'input in base al sistema operativo sulle quali devono girare.
Per quanto riguarda la possibilità di utilizzare OGL nel proprio linguaggio preferito, nonostante essa sia stata sviluppata inizialmente per essere utilizzata attraverso il linguaggio C (a differenza di architetture più complesse come quella adottata dalle DirectX che si basa sul Component Object Model COM), è disponibile in un'ampia varietà di linguaggi tra i quali C++, Java, Delphi e il neonato C#.
Mentre le case sviluppatrici di videogiochi su sistemi Windows si dividono, così come tanti programmatori, sulla questione DirectX Vs OpenGL, in ambiente Linux, ancora piuttosto estraneo all'utilizzo come Desktop, OGL ha una netta predominanza. Molto probabilmente grazie alla sua larga diffusione e grazie al fatto che è sempre più supportata da diverse distribuzioni sarà alla base dello sviluppo del mercato dei videogames sui sistemi *nix.
L'apporto del sistema operativo alla programmazione OpenGL. Le API GL Extensions.
OpenGL è una libreria grafica molto potente ma per poterne sfruttare le capacità ed apprezzarne i risultati a schermo è necessario prima "collegare" il sistema operativo con essa, cioè si deve creare una zona dello schermo ben definita dove OpenGL e il sistema operativo concordino sul tipo di pixel da utilizzare, sulle sue caratteristiche e sulle rispettive competenze.
Solitamente la zona del video nella quale intendiamo disegnare è la classica finestra oppure lo schermo intero (modalità fullscreen), mentre il tipo di pixel rappresentato viene chiamato pixel format.
Una prima soluzione è quella di utilizzare la libreria GLUT (GL Utility Toolkit), una libreria che permette di scrivere codice per la creazione e la gestione delle finestre indipendente dal sistema operativo su cui si sta lavorando, una sorta di interfaccia standard. Nonostante sia una proposta allettante è poco utilizzata perchè è penalizzante in termini di prestazioni e si ha un controllo ridotto sulle impostazioni di alcune paramentri specifici del sistema.
Proprio per migliorare l'interazione tra sistemi operativi e OpenGL i primi dispongono di alcune API (Application Program Interface) conosciute come OpenGL Extension, create appositamente per comunicare con tale libreria.
Queste API si possono trovare nei seguenti Sistemi Operativi:
- Windows - WGL Extension (a partire dalle versioni 95 e NT)
- Apple Macintosh - AGL Extension
- IBM OS/2 Warp - PGL Extension
- X Window System - GLX Extension
Naturalmente per quanto riguarda X Window System di Linux/Unix è necessario far notare che a differenza di Windows, dove la GUI (Graphic User Interface) è parte del Kernel, esso non è altro che il Server grafico ed è trattato dal sistema operativo come un qualsiasi processo. In particolare il Server XFree86 è il più diffuso.
Il procedimento per collegare il Sistema Operativo ad OpenGL prevede la creazione di una finestra attraverso le normali API del Window System, la creazione del contesto OpenGL (glContext) e l'assegnazione di quest'ultimo alla finestra.
Il glContext riveste un ruolo molto importante perchè è su di esso che andremo a disegnare, evitando di utilizzare le API di disegno predisposte dal Window System.
Se sulla macchina dove viene eseguito un programma che si appoggia ad OpenGL non sono presenti i relativi driver non sarà possibile creare un Direct Render Context, ciò significa che l'applicazione non sarà in grado di creare il glContext e noi non vedremo nulla.
Le OpenGL extension più importanti che i sistemi operativi mettono a disposizione riguardano:
- Le richieste di informazioni sulle capacità dell'implementazione (hardware o software) OpenGL installata sulla macchina;
- La scelta di un pixel format adatto alle nostre richieste;
- La creazione e la distruzione di un glContext;
- L'assegnamento del glContext creato alla finestra del sistema operativo;
- La sincronizzazione delle operazioni di disegno con le richieste del sistema operativo;
- Lo scambio dei buffer;
- La creazione dei font;
Le API di sicronizzazione evitano che il Window System esegua delle chiamate sul programma quando OpenGL non ha ancora concluso il proprio lavoro e viceversa, ciò si dimostra di una certa importanza quando il programma client e il server OpenGL non sono sulla stessa macchina.
Lo scambio dei buffer è fondamentale per tutte le applicazioni OpenGL che normalmente utilizzano la tecnica del doppio buffer. Vale a dire che mentre viene visualizzato il buffer A le operazioni di disegno vengono svolte nell'area di memoria del buffer B, quando tali operazioni sono concluse i due buffer verranno scambiati, B verrà visualizzato mentre A sarà pronto per essere modificato. Grazie a tale tecnica si risolvono i fastidiosi problemi di sfarfallio dovuti al tentativo del monitor di visualizzare la memoria video quando si sta ancora disegnando su di essa.
Infine per quanto riguarda le funzioni per la creazione dei font, che si rivelano molto utili, hanno il compito di facilitare al programmatore il compito di visualizzare del testo in modalità grafica. Tramite queste funzioni è infatti possibile creare i bitmap di tutti i caratteri dei font disponibili sul sistema.
Il fatto che lo sviluppo delle API per l'interazione di OpenGL sia curato direttamente dai sistemi operativi facilita enormemente il lavoro della libreria che si deve preoccupare solamente di fornire una interfaccia standard (il glContext) valida per tutti i sistemi e quindi altamente portabile.
OpenAL (Open Audio Library) è una libreria per la riproduzione e la manipolazione di effetti sonori sviluppata seguendo lo stile della più conosciuta libreria grafica OpenGL.
Si tratta di un software multipiattaforma grazie a una interfaccia di programmazione indipendente dall'hardware ed è disponibile su sistemi operativi Linux, Windows, MacOS, FreeBSD, BeOS e OS/2.
Sviluppata dalla Creative Labs e dalla Loki Entertainment AL è stata pensata per essere utilizzata nel mondo della riproduzione audio 2D - 3D, ciò significa che si rivela un ottima scelta per applicazioni quali videogiochi 3D e software di simulazione in genere.
La somiglianza ad OpenGL oltre che nel nome si rivela nella filosofia di progettazione e nella sua implementazione, risulta quindi notevolmente semplice includere codice AL all'interno di applicazioni GL già sviluppate.
Dato che AL si è dimostrata un ottimo prodotto la maggior parte delle nuove applicazioni 3D Linux ne fanno uso mentre in Windows sta cominciando a farsi strada ponendosi come seria alternativa a DirectSound, la libreria audio delle DirectX.
OpenAL può vantare tra i propri "clienti" alcune giochi di notevole caratura come Unreal Tournament 2003 della Epic Games e Soldier Of Fortune 2 della Raven Software.
Compito primario di OpenAL è quello di fornire al programmatore una serie di API per posizionare fonti audio in un mondo tridimensionale tenendo in considerazione i parametri che potrebbero influenzarla quali:
- Distance-based attenuation distanza dell'ascoltatore
- Position-based panning posizione dell'ascoltatore
- Doppler effects effetto Doppler
- Sound radiation dispersione del suono attraverso un campo acustico
- Sound reverb riverbero del suono (ancora in fase di implementazione)
Sono presenti anche funzioni di utilità per il caricamento di file .WAV e .mp3 oltre che alla possibilità di accedere alle estensioni della Creative EAX (Environmental Audio Extension).
Altre informazioni sono disponibili sul sito ufficilale www.openal.org.
Al momento nonostante una buona comunità di sviluppatori OpenAL è ancora in uno stadio primitivo ma, come dimostrano la scelta adoperata da Epic Games e dalla Raven Software, ha un grande potenziale e buone probabilità di diventare un punto di riferimento nel campo audio così come OpenGL lo è in quello della grafica.
Procedura di installazione della libreria audio OpenAL in un sistema Linux.
Per installare AL in Linux è necessario scaricare i sorgenti dal server CVS della Creative:
[alberto@Apollo13 download]$ cvs -d:pserver:[email protected]:/usr/local/cvs-repository login
Logging in to :pserver:[email protected]:2401/usr/local/cvs-repository
Utilizzare la password "guest"
CVS password:
[alberto@Apollo13 download]$ cvs -d:pserver:[email protected]:/usr/local/cvs-repository co openal
cvs server: Updating openal
U openal/CHANGES
U openal/COPYING
U openal/CREDITS
U openal/INSTALL
U openal/README
cvs server: Updating openal/beos
cvs server: Updating openal/beos/include
cvs server: Updating openal/beos/include/AL
...
L'operazione crea una directory openal contenente una subdirectory per ogni piattaforma supportata. Nel caso si voglia scaricare i sorgenti della sola implementazione Linux si può indicare come path al CVS openal/linux
e in seguito openal/include
per gli header file in comune a tutte le implementazioni.
Una volta terminato il download dei sorgenti si deve procedere alla compilazione:
Lanciare lo script autogen.sh
[alberto@Apollo13 linux]$ ./autogen.sh
Lanciare configure impostando la directory di installazione, normalmente /usr/local
, più eventuali opzioni.
Le piu' importanti sono:
--enable-optimization Abilita l'ottimizzazione
--enable-debug Abilita il debug
--enable-smpeg Abilita il supporto smpeg necessario per il caricamento dei file mp3 (la libreria smpeg deve però essere già installata sul sistema).
Una lista completa è disponibile lanciando configure --help
[alberto@Apollo13 linux]# ./configure --prefix=/usr/local
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for gcc... gcc
...
Lanciare make
[alberto@Apollo13 linux]# make
cd jlib && gmake all
gmake[1]: Entering directory `/home/alberto/download/openal/linux/jlib'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory `/home/alberto/download/openal/linux/jlib'
cd src && gmake all
gmake[1]: Entering directory `/home/alberto/download/openal/linux/src'
gcc -shared \
-Wl,"-soname,libopenal.so.0" \
...
Prima di installare la libreria è bene sincerarsi che questa funzioni attraverso dei programmi di test scaricati insieme ai sorgenti:
[alberto@Apollo13 linux]# cd test
E' necessario compilare anche questi:
[alberto@Apollo13 linux]# make
gcc -I../src -I../include -I../../include -I../audioconvert -g -O2 -fPIC -Wshadow -Wall -W -Wbad-function-cast -Wcast-qual
-Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wimplicit-function-declaration -Waggregate-return -Winline -Wpointer-arith -fno-common -ansi
...
I programmi di test dimostrano le varie capacità di OpenAL. Se questi funzionano è finalmente possibile installare la libreria.
Lanciare make install da root:
[root@Apollo13 linux]# make install
cd jlib && gmake all
gmake[1]: Entering directory `/home/alberto/download/openal/linux/jlib'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory `/home/alberto/download/openal/linux/jlib'
cd src && gmake all
gmake[1]: Entering directory `/home/alberto/download/openal/linux/src'
gcc -shared \
-Wl,"-soname,libopenal.so.0" \
...
Ora la libreria OpenAL è disponibile.