marce’s blog

Venerdì scorso son tornato nella mia patria dove mi aspettava una 3 giorni ad Unreal Tournamen 2004 al TLP.

Ovviamente non avevo né il gioco installato né sufficiente spazio sulla misera, inutile e pronta ad essere vaporizzata partizione di Windows. Mentre qui, sulla Gentoo, c’erano almeno 14 Gb liberi, un ebuild pronto per installare ut2004 ma dovevo far i conti con i 64 Bit nativi del sistema.

Dopo vari sfriccicamenti sono arrivato a capire che:

• UT2004 ha un eseguibile a 64 bit.
• Richiede la libstdc++-v3.3 che è facilmente installabile con il gcc-3.3.6. Però dopo, per evitare conflitti tra i compilatori (avevo il 4.1.2), m’è bastato creare un link simbolico alla libreria libstdc++.so.5 presente nel vecchio gcc appena installato per poi tornare al compilatore di base un pacchetto che contiene la sola libreria senza dover installare tutto il vecchio compilatore.
• Siccome usa OpenAL e mi crashava se attivavo il supporto all’ALSA, m’è toccato caricare i moduli per l’OSS (il predecessore di ALSA) con un semplice modprobe snd-pcm-oss. Dato che avevo ESD, il mixer software di gnome, ho dovuto terminarlo prima di avviare il gioco altrimenti il device /dev/dsp risultava occupato. ho notato che supporta una grande quantità di backend per l’audio oltre ad alsa e oss: direttamente ESD o le librerie SDL. La libsdl-1.2.11 può essere compilata con il supporto appunto per l’ALSA (cosa che tra l’altro la gentoo fa di base). Quindi per far andare l’audio senza problemi di sorta basta inserire o modifcare in ~/.openalrc la riga:

(define devices '(sdl))

• Per avere maggiori performace si può obbligare UT2004 a caricare direttamente le librerie di sistema invece che le sue poiché potrebbero essere ottimizzate per l’architettura o anche semplicemente più recenti. Nella cartella UT2004/System ci sono due file da rinominare in qualcos’altro a piacere e al loro posto sostituire un link simbolico con:
  • libSDL-1.2.so.0 -> /usr/lib/libSDL-1.2.so.0
  • openal.so -> /usr/lib/libopenal.so

  Questa sostituzione l’avevo già fatta di mia spontanea volontà, ma oggi ho avuto la conferma leggendo un forum…

Come se non bastasse, per poter tornare velocemente al desktop, ho lanciato il gioco in una nuova sessione di X con il comando:

xinit `which ut2004` -- :1

Dove la sintassi è xinit `which [comando]` [prametri] — :DISPLAY. Se invece di usare which per ottenere il path assoluto dell’eseguibile si usa ad esempio solamente “ut2004″, nel nuovo server X nel DISPLAY :1 verrà eseguito un xterm al cui interno verrà lanciato il comando passato. Di conseguenza questo non permette di fornire dei parametri o argomenti al programma ma si può vedere l’output sulla console.

Nel caso in cui non parta il nuovo server e si vedono dei messaggi tipo “autenticazione non valida” o qualcosa del genere, bisogna fornire tramite xauth dei parametri validi anche per il display 1 e non sono per quello principale (solitamente lo 0).

xauth list
xauth add .... :1

Scopiazzando pari pari una delle entry che compare con il primo comando.