Jouer sous FreeBSD

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
74
Mois de parution
septembre 2014
Spécialité(s)


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




Article rédigé par

Les derniers articles Premiums

Les derniers articles Premium

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Migration d’une collection Ansible à l’aide de fqcn_migration

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Distribuer du contenu Ansible réutilisable (rôle, playbooks) par l’intermédiaire d’une collection est devenu le standard dans l’écosystème de l’outil d’automatisation. Pour éviter tout conflit de noms, ces collections sont caractérisées par un nom unique, formé d’une espace de nom, qui peut-être employé par plusieurs collections (tel qu'ansible ou community) et d’un nom plus spécifique à la fonction de la collection en elle-même. Cependant, il arrive parfois qu’il faille migrer une collection d’un espace de noms à un autre, par exemple une collection personnelle ou communautaire qui passe à un espace de noms plus connus ou certifiés. De même, le nom même de la collection peut être amené à changer, si elle dépasse son périmètre d’origine ou que le produit qu’elle concerne est lui-même renommé.

Les listes de lecture

8 article(s) - ajoutée le 01/07/2020
Découvrez notre sélection d'articles pour faire vos premiers pas avec les conteneurs, apprendre à les configurer et les utiliser au quotidien.
11 article(s) - ajoutée le 02/07/2020
Si vous recherchez quels sont les outils du DevOps et comment les utiliser, cette liste est faite pour vous.
8 article(s) - ajoutée le 02/07/2020
Il est essentiel d'effectuer des sauvegardes régulières de son travail pour éviter de perdre toutes ses données bêtement. De nombreux outils sont disponibles pour nous assister dans cette tâche.
Voir les 58 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous