Jouer sous FreeBSD

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
|
Mois de parution
septembre 2014
|
Domaines


Résumé
Pourquoi jouer sous un *BSD qui n'est pas vraiment conçu pour cela ? Pourquoi ne pas coder simplement ? Parce que nous sommes des êtres humains et que, parfois, jouer un peu ça fait tout simplement du bien !

Body

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


Sur le même sujet

Crostini : débridez Chrome OS avec les applications Linux

Magazine
Marque
Linux Pratique
Numéro
120
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Chrome OS est basé sur un système Linux (Gentoo), mais l'approche adoptée par Google est de limiter les possibilités de paramétrage et d'installation d'applications. Pour améliorer la polyvalence de son système sans remettre en cause son modèle sécuritaire, Google a, par la suite, introduit Crostini : une solution basée sur LXC pour que les utilisateurs de Chrome OS puissent travailler avec Linux dans un conteneur.

Analysez, diagnostiquez et dépannez votre système avec Sysdig

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Un système ne manque pas d’avoir des problèmes matériels, de plantage système, de performances, au niveau utilisateur ou noyau. Et malheureusement, les systèmes Linux ne sont pas exempts de ces problèmes à dépanner. Mais heureusement, Linux n’est pas en reste d’outils pour vous aider à diagnostiquer les problèmes. Des outils simples comme top pour surveiller l’usage CPU, ou ps pour les processus. Vous voulez tracer un appel système d’un processus : strace est votre ami. tcpdump, ou tshark vous aideront à inspecter le trafic réseau en ligne de commandes. Vous avez donc beaucoup d’outils à disposition, dans l’esprit « un outil précis pour une tâche unique », cher à Linux. Le problème c’est que lorsque l’on dépanne un système, on n’a pas le temps de se souvenir de tous les outils à disposition et taper toutes ces commandes en live. Outils qui ont chacun une philosophie différente, une interface d’entrée et de sortie différentes, ce qui peut poser soucis dans des situations stressantes et créer de la confusion lors d’occasions qui demandent de réagir dans l’urgence. Surtout que la plupart de ces outils ne sont pas pensés et optimisés pour être utilisés dans des conteneurs, plateformes de plus en plus utilisées et répandues.

Mettez en place une gestion efficace de vos journaux système avec Loki

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Bien avant les métriques et les graphiques de performances, les journaux système étaient la première source pour dépanner un système ou un service qui posait problème. Et ils le sont toujours : par défaut, sans aucune configuration, n’importe quel système Linux ou service journalise son activité et ses erreurs. Mais tout comme les métriques, si vous commencez à avoir à administrer plusieurs systèmes, la question se pose de centraliser ces journaux pour pouvoir les consulter simplement. Et quel stockage utiliser ? Des solutions, privées comme Splunk, ou libres comme Kibana sont déjà très populaires. Mais leur type de stockage (ElasticSearch pour Kibana), avec un indexage pour la recherche plein texte, prend beaucoup de place à l’utilisation et en sauvegarde, pour un intérêt limité dans la majorité des cas d’utilisation. Dans cet article, nous allons découvrir Loki, une solution toute récente, plus légère, pour gérer vos journaux.

Basez votre supervision sur des logs de qualité avec Rsyslog

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Les événements systèmes (aussi nommés logs dans la suite de l’article) sont des éléments déterminants pour la supervision du bon fonctionnement du système d’exploitation. Leur intérêt est souvent sous-coté aussi bien du point de vue maintenance du système que de sa sécurité. Cet article a pour ambition de poser les bases d’une bonne gestion des logs.

Neovim : dépoussiérez votre Vim

Magazine
Marque
Linux Pratique
HS n°
Numéro
47
|
Mois de parution
juillet 2020
|
Domaines
Résumé

Une application historique, puissante, populaire avec une base utilisateurs énorme, une compatibilité multiplateforme ultra-large, un code et une API quasi inmaintenables, dirigée par un Dictateur Bienveillant À Vie comme chef de projet et unique développeur : Vim présente toutes les caractéristiques d’un projet libre à succès. Et donc aussi tous les problèmes qui irritent ses utilisateurs et les contributeurs qui auraient le courage de participer à son développement. Dans cet article, nous allons découvrir Neovim, un fork de Vim né de la frustration d’utilisateurs de l’éditeur.

Par le même auteur

Jouer sous FreeBSD

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
|
Mois de parution
septembre 2014
|
Domaines
Résumé
Pourquoi jouer sous un *BSD qui n'est pas vraiment conçu pour cela ? Pourquoi ne pas coder simplement ? Parce que nous sommes des êtres humains et que, parfois, jouer un peu ça fait tout simplement du bien !