Il faut voir les choses en face : le meilleur système d'exploitation pour un PC qui ne sert qu'à jouer est Windows, car l'immense majorité des jeux et des drivers sont architecturés pour cette plateforme.
Linux devient une possibilité de plus en plus crédible, grâce à la maturité de Wine, à des projets comme SteamOS, et à la nouvelle niche du GMGPU, qui motive les constructeurs de cartes graphiques autant que le matériel de jeu haut de gamme.
Les autres UNIX n'ont pas vraiment d'avantage technique sur Linux pour être compétitifs sur des jeux communs, et n'ont pas une part de marché suffisante pour intéresser les constructeurs. Ils ne bénéficient pratiquement que des avancées de Linux qu'ils peuvent porter.
Donc, pour un PC dédié uniquement au jeu, les UNIX BSD n'ont pas vraiment d'intérêt par rapport à Linux ou à Windows. Mais tout le monde n'a pas les moyens de dédier un PC uniquement au jeu. Que ce soit pour des raisons financières, ou d'encombrement, ou même simplement philosophiques par rapport à la proportion entre temps passé à jouer et temps passé à faire autre chose.
On peut certes s'orienter vers le double boot ou la virtualisation, mais ces deux solutions limitent les autres choses que l'on peut faire avec le PC considéré. Donc, on joue sous un *BSD principalement parce qu'on fait surtout autre chose avec, et le jeu est un bonus. Si on peut, pourquoi s'en priver ?
1. Les contraintes préalables
Les autres UNIX bénéficient des technologies de jeu pour Linux qu'ils peuvent porter. La portabilité est très inégale, et finalement assez peu de combinaisons de matériel et de systèmes d'exploitation permettent d'apprécier les jeux raisonnablement récents. Depuis de nombreuses années, les jeux ne sont plus vraiment limités par le CPU ou le matériel généraliste, mais par la carte graphique et son driver. Dans le monde des systèmes d'exploitation libres, les drivers propriétaires gardent de l'avance, même si elle s'amenuise d'année en année.
D'autre part, les drivers libres de Linux, à la poursuite des drivers propriétaires, se basent sur des technologies sans cesse changeantes : DRI, DRM, GEM, KMS, etc. Cette frénésie de technologies logicielles fortement couplées au noyau Linux sont difficiles à porter, et convient mal à la philosophie d'ingénierie logicielle réfléchie des UNIX BSD. Or, il se trouve que nVIDIA propose des drivers propriétaires pour FreeBSD, qui se composent d'un module noyau et de drivers userland, sans autre prérequis. C'est ainsi que la meilleure plateforme de jeu PC en dehors de Windows et Linux, est un PC supporté par FreeBSD avec une carte graphique nVIDIA.
2. Le jeu sous FreeBSD
2.1 Jeux natifs
À ma connaissance, il n'y a pas de jeu écrit directement pour FreeBSD. Il y a en revanche un bon nombre de jeux open source qui sont présents dans l'arbre des ports, et dont le fonctionnement est impeccable.
2.2 Jeux Linux
Il existe certains jeux propriétaires disponibles sous forme de binaires pour Linux. Et certains d'entre eux fonctionnent avec le « linuxulator », l'émulation Linux de FreeBSD. Malheureusement, là encore, la philosophie des UNIX BSD et la main d'œuvre limitée font que le linuxulator n'avance pas aussi vite que Linux lui-même. Entre le peu de jeux propriétaires sous Linux et les limites du linuxulator, je doute que cette option soit souvent utilisable. En particulier, Steam for Linux n'est pas (encore) utilisable.
Par contre, il y a plusieurs années, j'avais eu du succès avec Neverwinter Nights et avec la démo de Doom 3 (depuis libéré).
2.3 Jeux Windows
Le gros des jeux restent des binaires pour Windows 32-bits, et Wine permet de les faire fonctionner à peu près aussi bien que sous Linux. L'AppDB de Wine [1] est donc une bonne liste des jeux Windows utilisables sous FreeBSD.
À noter que comme Wine n'est pas un émulateur, il doit être lancé dans un contexte 32-bits. Ça ne pose aucun problème si le système d'exploitation entier est 32-bits, mais ça impose une certaine gymnastique sous FreeBSD/amd64, gymnastique qui a très bien été automatisée dans le port emulators/i386-wine.
Il reste cependant un avantage à utiliser l'ancienne méthode, à base d'une installation de FreeBSD/i386 dans un chroot : la liberté de placer où on veut les fichiers de la base (voir [2] pour aller plus loin). C'est très utile lorsqu'on veut la placer sur un SSD pour améliorer les temps de chargement. Le gain est moindre que placer la base Windows (drive_c) sur SSD, mais ces deux gains se cumulent.
3. La capture de jeu
Jouer tout seul sur mon PC, c'est bien. Jouer avec les autres, c'est mieux. Et partager ses exploits en privé ou sur des réseaux sociaux, c'est encore mieux.
3.1 Capture vidéo
Une question qui se pose rapidement lorsqu'on joue en dehors de Windows, est comment remplacer FRAPS ou ses concurrents moins connus de capture vidéo. J'ai longtemps cru que c'était peine perdue, jusqu'à ce que je découvre qu'il existe une solution efficace et libre : ffmpeg... avec toute la pénibilité de mise en œuvre qui le caractérise...
Pour utiliser la capture vidéo de ffmpeg, il faut l'option X11GRAB, qui n'est pas activée par défaut dans les ports de FreeBSD. Il faut donc soit l'installer directement depuis les ports, soit déployer une instance personnelle de poudriere pour créer un paquet avec cette option (c'est plus simple que ça en a l'air). Ensuite, la bonne invocation de ffmpeg permet de capturer la vidéo. J'utilise personnellement la ligne de commandes suivante :
$ ffmpeg -f x11grab -s 1680x1050 -r 25 -i "${DISPLAY}" -vcodec libx264 -vpre ultrafast -crf 18 /home/nat/video/incoming/$(date +%Y-%m-%d-%H-%M-%S).avi
Il faudra bien sûr adapter la résolution de l'écran, et éventuellement adapter les paramètres d'encodage pour trouver le bon compromis entre consommation CPU et transfert vers le disque dur. Les paramètres ci-dessus produisent des fichiers assez gros, de trop bonne qualité, pour pouvoir tranquillement les ré-encoder plus tard, avec une commande du type :
$ ffmpeg -i video_source.avi -c:v libx264 -preset veryslow -crf 25 final.mp4
C'est à cette occasion que j'ajoute éventuellement une bande son : soit de la musique pour faire comme beaucoup de vidéos de jeux sous YouTube, soit une capture des conversations sous Mumble pour analyser les matchs d'arène World of Warcraft et progresser.
3.2 Capture du son
Je me suis souvent demandé pourquoi tellement de vidéos de jeux n'incluent pas le son original du jeu. Je ne sais d'ailleurs toujours pas ce qui limite les joueurs sous Windows ou Linux. Sous FreeBSD, c'est le système de son qui est limitant : la capture du son se révèle bien plus compliquée que la capture vidéo.
La solution la plus facile est la méthode low-tech, en bouclant la sortie (probablement analogique) de la carte son sur une de ses entrées (probablement analogique aussi), ce qui permet d'enregistrer le son du jeu au prix d'une perte de qualité (sauf bouclage numérique) et de ne pas pouvoir l'entendre en direct.
Une autre solution est de passer par OSSv4, disponible via le port audio/oss, après avoir recompilé son noyau pour enlever le support audio de base. On peut alors activer le loopback au moyen de l'option vmix_loopdevs=1 dans /usr/local/lib/oss/conf/osscore.conf. Cette option fait apparaître un device loop0 qui peut être utilisé pour enregistrer le jeu et toutes les autres applications qui émettent du son, au moyen d'une commande comme :
$ ffmpeg -f oss -i /dev/oss/oss_hdaudio0/loop0 -f x11grab -s ...
Malheureusement, si OSSv4 propose un bon nombre de fonctionnalités intéressantes, il ne semble pas encore complètement mûr ni facile d'accès. De la même façon, PulseAudio propose des fonctionnalités similaires, pour un coût technique qui a l'air du même ordre. Enfin, une autre piste avec le système de son de base de FreeBSD, est d'enregistrer directement sur le nœud OSS, avec une commande du type :
$ ffmpeg -f oss -i /dev/dsp0.0 -f x11grab -s ...
Une première limite de cette solution est que ffmpeg doit être lancé avant le jeu ou quoi que ce soit qui utilise le son, sinon il ne pourra pas prendre le device. Ça veut dire n'enregistrer que des sessions complètes de jeu (et supporter la consommation d'espace disque et le montage plus lourd). Ce problème pourrait être contourné en lançant un premier ffmpeg qui capture le son en streaming, et lancer extemporanément un ffmpeg qui fait la capture vidéo en lisant le son en streaming, mais ce montage commence à devenir un peu complexe. Une autre limite, plus sévère, est qu'elle n'est possible que si le driver et la carte son le supporte. Or, ce n'est pas le cas pour le driver snd_hda, qui gère la plupart des systèmes audio intégrés. Dans ce cas, il reste la possibilité d'utiliser un programme comme vsound, qui utilise LD_PRELOAD pour intercepter les communications du programme avec OSS pour les enregistrer dans un fichier brut. Autant dire ajouter encore un étage à cette usine à gaz...
3.3 Streaming
Avec l'explosion des débits, il devient possible d'envoyer les vidéos de jeux directement vers Internet en streaming, une fois encore avec ffmpeg.
Je ne suis pas très fan de cette pratique, principalement parce que comme expliqué en introduction, je ne fais pas que jouer sur mon PC de jeu, parfois je change même de bureau pendant les temps de chargement ou d'attente d'autres joueurs. Or, X11GRAB est attaché à un écran et non pas à une fenêtre, et je n'ai pas forcément envie de diffuser au monde entier toutes mes activités sur ce PC.
Cela étant, pour ceux qui sont adeptes, j'ai essayé pour vous, et ffmpeg arrive très bien à envoyer ce qu'il capture (vidéo, et éventuellement son) vers twitch.tv, avec une ligne de commandes de la forme :
$ ffmpeg [son] -f x11grab -s 1680x1050 -r 15 -i :0.0 -c:v libx264 -preset fast -pix_fmt yuv420p -s 1280x800 -threads 0 -f flv rtmp://live.twitch.tv/app/${TWICH_APP_KEY}
Conclusion
Jouer sous FreeBSD n'est guère plus complexe que sous Linux même si, comme nous avons pu le voir, la référence pour le jeu (pour les éditeurs) reste Windows. Au prix de quelques efforts et en suivant les pistes données dans cet article, vous devriez y arriver...
Références
[1] Wine Application Database : http://appdb.winehq.org/
[2] Installation de FreeBSD/i386 dans un chroot : http://instinctive.eu/weblog/044-resurrection-de-yulai
