SFML : WTF ?

  • La version 1.3 est sortie il y a peu de temps, mais SFML n'est toujours pas intégré dans l'arbre Portage de la Gentoo
    • ne partez pas, ce billet peut également servir aux personnes qui n'ont pas le port disponible pour leur distribution.
  • Un ebuild pour la version 1.2 est disponible pour la Gentoo.
    • Ce n'est pas que je n'ai pas confiance, mais je préfère compiler cette bibliothèque à part.


Compilation

  • Vérifiez que vous avez les dépendances:
    • OpenAL
    • libsndfile
    • freetype
    • et une carte graphique supportant OpenGL en hard (sinon ça va se trainer)
  • Décompactez l'archive SFML dans votre répertoire de sources.
  • make
  • Voila, c'est prêt. Simple et de bon goût, un bon point pour SFML.
    • Ne faites surtout pas un make install


Compiler les samples

  • SFML est certe compilé, mais les libs et les includes ne sont pas disponibles directement.
    • Nous allons voir comment utiliser SFML sans pourrir notre /usr/lib et notre /usr/include.
    • Vivement que ce soit intégré dans Portage, quand même.
  • Allez dans le répertoire lib de SFML et créez des liens symboliques sur les bibliothèques, sans le numéro de version.
    • Si vous ne faites pas ceci, le linker ne va rien trouver (il cherche les libs sans les numéros de versions).
    • strace -f -e open avant la commande de link si vous voulez voir ce que le linker recherche.
    • Fred qui connait bien le shell vous file son batch:
    • for a in *.so.1; do ln -sf $a ${a%%.1}; done


  • Allez dans le répertoire samples/sound
    • Modifiez le Makefile, qui va devenir ceci :
EXEC = sound.elf
EXECPATH = ../bin
OBJ  = Sound.o
CFLAGS=-I../../include
LDFLAGS=-L../../lib

all: $(EXEC)

$(EXEC): $(OBJ)
        $(CC) $(LDFLAGS) -o $(EXECPATH)/$@ $(OBJ) -lsfml-audio -lsfml-system -Wl,-rpath=../../lib

%.o: %.cpp
        $(CC) -o $@ -c $< $(CFLAGS)

.PHONY: clean mrproper

clean:
        @rm -rf *.o

mrproper: clean
        @rm -rf $(EXECPATH)/$(EXEC)
  • Explications pour les variables:
    • les variables CFLAGS et le LDFLAGS indiquent au compilateur où trouver les includes et les libraries.
    • la variable EXEC prend le nom de sound.elf: .elf est mon extension d'exécutables Linux, ignorée lors de mes archivages.
  • Explications pour le -Wl
    • -Wl permet de passer des options au linker
    • -Wl,-rpath=../../lib indique au linker de hardcoder l'emplacement des bibliothèques chargées dynamiquement.
    • Ceci évite d'avoir à préciser avant l'exécution l'emplacement non-standard de nos bibliothèques avec l'export de LD_LIBRARY_PATH (ce qui fonctionnerait également)
    • Bien entendu, les exécutables générés de cette façon ne sont plus distribuables, à moins de dupliquer la hiérarchie du filesystem. Ce n'est de toutes façons pas souhaitable, et juste une façon de gagner du temps pour nos essais.
  • J'ai ajouté la variable $(EXECPATH) qui pointe sur le répertoire samples/bin.
    • Ce répertoire contient les données utilisées par les programmes d'exemples.
    • Sinon, vous pouvez toujours déplacer les exécutables après compilation, mais c'est une perte de temps.
  • J'ai également modifié la cible de $(OBJ), c'est un détail.


  • Lancement du test sound.elf
    • Allez dans le répertoire samples/bin et lancez sound.elf
    • Attention, sound sera peut être présent, mais il a été compilé lors de la compilation des sources, et ne trouvera pas les libraries. Il faut donc bien lancer sound.elf (faire le ménage dans /samples/bin ne serait pas une mauvaise idée).
    • Lisez le paragraphe suivant si vous avez un message d'erreur de ce type (le segfault est offert par la maison) :
open /dev/[sound/]dsp: No such file or directory
Failed to open the audio device



OSS 117 : délire à Alsa City

  • Donc le son ne sort pas de vos haut-parleurs. How bad.
  • Pour ma part, j'ai vérifié, OpenAL est bien compilé avec le support Alsa.
  • strace -f -e open ./sound.elf
open("/dev/sound/dsp", O_WRONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
open("/dev/dsp", O_WRONLY|O_NONBLOCK)   = -1 ENOENT (No such file or directory)
open /dev/[sound/]dsp: No such file or directory
Failed to open the audio device
  • OpenAL (ou SFML via OpenAL) semble insister pour utiliser OSS à la place de Alsa.
  • Mon noyau a été compilé sans OSS (support direct ou émulation), avec uniquement Alsa.
  • J'ai deux solutions
    • recompiler un noyau avec un support OSS (émulé ou pas).
    • installer alsa-oss
  • Je ne recompilerai pas pour si peu. Mais qu'est-ce que alsa-oss ? 
aoss is an OSS to ALSA redirector. You can use it to run OSS-Applications with an ALSA Sound system so you can use multiple programs with audio-output at a time.
  • Merci à Frédéric Jolliton pour le tuyau sur alsa-oss dont je ne connaissais pas l'existence.
  • Le programme de test sound.elf fonctionne avec alsa-oss, mais ça crachouille pas mal.
    • aoss ./sound.elf
    • Jai fait un essai avec un support direct de OSS sur une autre machine, et ça fonctionne mieux (mais il y a des cliquetis dans le flux sonore).
  • La doc de SFML conseille d'installer une autre version de OpenAL : OpenAL-Soft.
    • OpenAL-Soft a l'air d'être compatible au niveau binaire, mais de poser d'autres problèmes si on en croit les forums de SFML.
  • Pas de solution miracle pour l'instant, donc.


Un successeur de SDL ?

  • La SDL est en trait plat à l'EEG depuis 3 ans (dernière version stable: 1.2.13).
    • Sur la mailing-liste SDL, il a été annoncé officiellement que la version 2.0 ne verrait jamais le jour.
    • Des doutes planent également sur la version 1.3. Mais, sait-on jamais...
  • SFML propose d'ores et déja des bindings intéressants: C, C++, Python, D (si si).
  • Les performances 2D sont plus que correctes, grâce à l'utilisation de OpenGL. SDL utilise pour sa part une écriture à l'ancienne dans le buffer video.
  • Reste à savoir si cette librairie sera maintenue, ou si il vaut mieux miser sur des librairies plus simples telles que GLFW.
  • Je continue à tester et je mettrai éventuellement à jour ce blog avec mes nouvelles découvertes.