Alt-F4 n°44 - Une nouvelle perspective 30-07-2021
traduit par bev, Firerazer
Vous vous souvenez du poisson d’avril de cette année ? C’était il y a un bon moment déjà, mais si ce jour-là vous avez visité le sousReddit de Factorio, vous avez probablement vu la vidéo hallucinante de arrow in my gluteus maximus. Si ce n’est pas le cas, ce numéro 44 de Alt-F4 vous mettra au courant et vous expliquera comment cette démonstration de magie noire a été réalisée !
Une nouvelle perspective sur “Une nouvelle perspective des trains dans Factorio” arrow in my gluteus maximus
Il y a deux mois, j’ai publié une vidéo intitulée : “A new perspective on trains in Factorio”. Si vous ne l’avez pas encore vue, regardez-la avant de lire l’article, car sinon, vous n’y comprendrez pas grand-chose.
Il se dit que certaines personnes auraient eu des maux de tête après avoir visionné cette vidéo. Vous êtes prévenus.
Ceux qui ont téléchargé le mod dont le lien figure dans la description savent qu’il s’agit en fait d’un poisson d’avril. Pour ceux qui ne l’avaient pas compris : j’en suis désolé. Quelques personnes m’ont demandé des détails sur la façon dont j’ai réalisé cette vidéo, alors j’ai décidé d’écrire une explication rapide. N’essayez pas ça chez vous.
J’ai lu que certaines personnes pensaient que j’avais extrait des modèles 3D du jeu. Ce n’est pas nécessaire, il s’agit d’une simple rotation de ce qui est affiché à l’écran. Si l’idée est simple, l’exécution est un peu plus compliquée. Le premier problème que vous rencontrez est que les écrans ne sont pas des cercles. Lors de la rotation, certaines parties de l’image sont donc coupées, tandis que d’autres parties, comme l’interface graphique, sont absentes.
J’ai fini par recourir à ma solution habituelle aux problèmes d’enregistrement avec Factorio : utiliser des captures d’écran à la place. Les captures d’écran en jeu ne sont pas soumises aux limitations de l’enregistrement normal d’un écran. Par conséquent, pour réaliser la vidéo, je prends simplement une capture d’écran à chaque tick sur une zone plus grande que celle qui est normalement visible. De cette façon, aucune partie de l’écran n’est coupée lors de la rotation.
Le problème suivant est que l’interface utilisateur pivote également, ce que nous ne voulons pas vraiment. Les captures d’écran viennent également à la rescousse ici. La commande take_screenshot() a une option appelée show_gui. L’astuce consiste à prendre deux captures d’écran à chaque tick, une avec l’interface utilisateur visible et une autre sans. Si nous ne retirons que les parties qui diffèrent, nous obtenons uniquement l’interface utilisateur, que nous pouvons ensuite superposer à la capture d’écran sans interface. C’est du moins ce qui était prévu. Divers problèmes d’édition vidéo ont rendu cette idée irréalisable. Par exemple, mon éditeur vidéo ne prend pas en charge les formats sans perte (ceux que j’ai pu trouver, j’en ai essayé plusieurs). Les petites différences d’encodage se répercutent donc sur l’affichage de l’interface utilisateur.
Cependant, j’ai découvert que dans les versions récentes de Factorio, l’interface utilisateur n’est plus liée à la position du joueur dans les captures d’écran. Elle est toujours visible, quelle que soit la partie de la carte que vous enregistrez. J’ai donc cherché une couleur éloignée des autres couleurs présentes dans le jeu. J’ai choisi le rose. J’ai modifié l’image de quelques bétons pour les rendre rose vif et j’ai désactivé les nuages. J’ai changé l’emplacement de la capture d’écran de mon interface utilisateur pour que seul du béton rose soit visible. De cette façon, je peux obtenir l’interface utilisateur en utilisant une sorte d’écran vert, ou plutôt rose dans ce cas.
Il y a eu toutefois quelques petits problèmes avec cette méthode. Il s’avère qu’il y a des parties transparentes dans l’interface utilisateur, notamment le panneau de détails qui s’affiche lorsque vous survolez des éléments avec votre souris. Il est devenu violet. J’ai fini par le supprimer manuellement de l’interface utilisateur, ce que personne ne semble avoir remarqué.
Ensuite, j’ai créé un petit mod qui jouait un son à chaque fois que je commençais à faire une capture d’écran, ce qui me permettait de synchroniser les sons du jeu avec les captures. De la même manière que les studios de cinéma utilisent un clap. Le mod écrivait également la valeur de game.players[1].vehicle.orientation dans un fichier texte. J’ai utilisé cette valeur pour calculer le nombre de rotations nécessaires, avec un lissage à l’aide de splines.
Je craignais que ces étapes ne soient pas suffisantes pour rendre le jeu crédible. Faire autant de captures d’écran ralentit énormément le jeu. Je craignais qu’il soit évident que les séquences avaient été accélérées en regardant mes mouvements dans le jeu. J’ai donc cherché un moyen d’accélérer l’enregistrement. Après avoir enregistré les captures d’écran, je les ai encodées au format MP4 avec FFmpeg. Alors pourquoi ne pas supprimer les intermédiaires et essayer de connecter FFmpeg directement à Factorio ? L’encodage des images en PNG et leur enregistrement sur disque sont des opérations coûteuses. Donc si je pouvais sauter ces étapes, ça irait beaucoup plus vite.
La première étape consisterait à extraire les données brutes de l’image (à ne pas confondre avec le format .raw) directement de Factorio au lieu de les encoder dans une image PNG. Je n’ai pas trouvé de moyen facile de le faire, mais il s’avère qu’une image .bmp en est très proche. Ce sont en fait les données de l’image à l’envers avec un en-tête devant. Donc ça devrait être beaucoup plus rapide à encoder qu’un fichier PNG.
Ensuite, il s’agissait de transférer l’image dans FFmpeg sans la sauvegarder d’abord sur le disque. Il s’avère que FFmpeg a des fonctionnalités intégrées pour le transfert d’images, donc un flux avec un nom et une extension .bmp a fait l’affaire. (Exemple de commande : ffmpeg -f image2pipe -framerate 60 -i - -r 60 -c:v libx264 -vf format=yuv420p -crf 1 example.mp4 -y < pipe.bmp)
Ne pas oublier de garder le flux ouvert entre les captures d’écran avec une commande de veille : sleep 10000000 > pipe.bmp, et d’arrêter cette commande à la fin pour laisser FFmpeg finir l’enregistrement. J’ai fait un test avec un faible nombre d’images par seconde et … ce n’est pas bon ! Qu’est-ce qui se passe ici ?
Le problème est que les images sont mélangées. Le rendu de Factorio est multithread. Alors qu’une image est toujours en cours d’écriture dans le flux, la suivante peut déjà commencer. En fait, les pixels des deux images sont mélangés. La solution consiste à forcer Factorio à attendre que l’image précédente soit affichée avant de commencer la suivante. On peut le faire en utilisant la commande game.set_wait_for_screenshots_to_finish() à chaque image. Cependant, cela ralentit tellement Factorio que l’on ne peut plus parler de temps réel. Bien que j’aie encore quelques idées pour l’accélérer, à ce stade, j’ai déjà passé beaucoup trop de temps sur ce projet et j’ai donc décidé d’utiliser une méthode qui a fait ses preuves, à savoir les rediffusions.
Factorio possède une merveilleuse propriété qui lui permet de ne pas devoir vérifier si le code des mods utilisés lors d’un enregistrement et lors de sa rediffusion est le même. J’ai donc d’abord enregistré une partie classique, à une vitesse normale. Puis j’ai modifié un de mes mods pour prendre des captures d’écran à chaque tick. Ainsi, lors de la rediffusion, Factorio commencera à prendre des captures d’écran. Ceci suppose que les modifications que vous avez apportées au mod ne changent pas l’état du jeu.
Malheureusement, en raison de l’utilisation de la rediffusion, j’ai dû couper quelques scènes. Je comptais montrer à quel point il est bizarre de construire des choses à partir d’une perspective tournée, mais il s’avère que Factorio n’enregistre pas la position de votre souris dans la rediffusion. L’interface utilisateur suit votre souris au moment de la lecture, et non la position de votre souris lorsque vous l’avez enregistrée.
Dans l’ensemble, ce fut un défi amusant et j’ai apprécié le fait de déstabiliser ainsi les joueurs de Factorio.
Contribuer
Comme toujours, nous attendons vos contributions pour les Alt-F4, que cela soit par la soumission d’un article ou en aidant pour les traductions. Si vous avez quelque chose d’intéressant en tête que vous souhaitez partager avec la communauté, vous êtes au bon endroit. Si vous n’êtes pas sûr, nous serons heureux de vous aider en discutant structure, contenu et idées. Donc si vous voulez vous impliquer dans les Alt-F4, rejoignez-le Discord pour ne rien rater !