Doom-htop : exécuter Doom dans l’outil de supervision de processus htop

(github.com/0x0mer)

2 points par GN⁺ 2024-04-22 | 1 commentaires | Partager sur WhatsApp

Implémenter DOOM avec htop

Aller dans le répertoire doomgeneric
Compiler avec la commande make -j8
Un fichier WAD (données du jeu) est nécessaire. Ce projet inclut freedoom1.wad (tous les crédits reviennent au projet Freedoom). Il est aussi possible de télécharger et d’utiliser la version shareware classique gratuite DOOM1.wad

Exécuter les commandes ci-dessous :

sed -i 's/update_process_names=0/update_process_names=1/' ~/.config/htop/htoprc
sudo ./doom-htop -iwad freedoom1.wad
htop -d 1 -s M_VIRT

L’ordre de lancement de doom-htop et htop n’a pas d’importance
sudo est nécessaire pour ouvrir le périphérique clavier. Si cela pose un problème de sécurité, il est possible de lancer sans sudo et de profiter uniquement de l’affichage graphique
Le -d 1 de htop sert à obtenir une fréquence de rafraîchissement de 10 FPS. -s M_VIRT sert à trier les processus par allocation de mémoire virtuelle
La commande sed est nécessaire car htop, par défaut, ne met pas à jour le nom des processus à chaque rafraîchissement

Travail réalisé à partir d’un fork du projet https://github.com/ozkl/doomgeneric
Ajout des fichiers main.c, keylogger.c, ascii_stuff.c et modifications partielles
Écriture d’un convertisseur simple image-vers-ASCII (la longue suite de if dans ascii_stuff.c)
Le processus Doom principal crée des processus enfants en nombre égal au nombre de lignes de l’image ASCII, puis crée un segment de mémoire partagée avec chacun d’eux
Le processus principal copie chaque ligne dans le segment mémoire du processus correspondant, et chaque processus enfant lit son propre segment pour écraser argv[0]
L’idée initiale était de trier les processus selon l’utilisation CPU, mais cela s’est révélé difficile. nice sous Linux a aussi été envisagé, mais comme l’utilisateur ne peut définir que 19 valeurs, l’idée a été abandonnée
L’idée d’utiliser l’allocation de mémoire virtuelle est alors apparue. Elle est spécifique à chaque processus
Même si tous les processus enfants allouent exactement la même quantité de mémoire, htop affiche les frames dans le bon ordre. Il est supposé qu’en cas d’égalité, le tri se fait selon l’heure de création
Un keylogger simple a été écrit pour ouvrir le périphérique clavier. Le jeu tourne toujours en arrière-plan, que htop soit lancé ou non

Testé uniquement sur Ubuntu 22.04
Sous WSL et Arch, le nom du périphérique clavier est différent. Un portage est nécessaire

Si le clavier ne fonctionne pas
- Vérifier la macro KEYBOARD_DEVICE dans main.c. Elle peut varier selon la plateforme
- Utiliser la commande ll /dev/input/by-path et choisir un périphérique contenant kbd
Si les frames se figent
- La commande sed n’a peut-être pas fonctionné
- Dans htop, aller sur F2 -> "Display options" -> cocher "Update process names on every refresh"
Erreur sed: can't read /home/<user>/.config/htop/htoprc: No such file or directory
- Cela se produit si htop n’a jamais été lancé. Lancer htop, le quitter, puis exécuter de nouveau sed
Si le processus Doom principal meurt et qu’il ne reste que des processus zombies
- Exécuter sudo pkill doom-htop

Lors d’un déplacement avec les touches fléchées, l’écran de htop bouge aussi, ce qui est gênant
Cela peut être résolu en changeant le focus après le démarrage de htop (par exemple en appuyant sur la touche a pour ouvrir le menu de sélection du processeur)

Représenter l’écran d’un jeu 3D en ASCII art est une idée originale. Cela semble aussi être un bon exemple pour dessiner des graphismes à l’écran en C à la manière de htop
Il est impressionnant que ce ne soit pas seulement un affichage ASCII, mais une véritable implémentation connectée au moteur du jeu
Le bon usage du projet doomgeneric pour réaliser cela avec peu de code mérite aussi d’être salué
Ouvrir directement un périphérique Linux pour capter l’entrée clavier peut ne pas fonctionner sous WSL ou sur d’autres OS. Il pourrait être utile d’envisager une bibliothèque de saisie clavier indépendante de l’OS
L’idée d’utiliser de la mémoire partagée pour échanger les données des frames ASCII entre processus parent et enfants est intéressante. C’est un bon exemple pour étudier l’IPC
L’idée d’injecter les graphismes ASCII dans les noms de processus de htop est créative. Mais cela entraîne aussi des effets secondaires, comme un écran qui bouge quand les noms de processus changent. Des améliorations semblent nécessaires
La licence semble être GPL, mais ce n’est pas clairement établi. En cas de réutilisation du code, il faut vérifier la licence

GN⁺ 2024-04-22

Ces commentaires portent sur un projet qui fait tourner le jeu Doom rendu en ASCII comme un processus via htop. Voici les points principaux :

Comparaison avec PSDoom : alors que PSDoom utilise Doom pour gérer les processus, ce projet fait l’inverse et permet de jouer à Doom à l’aide d’un gestionnaire de processus.
Évaluation technique : rendre le jeu en ASCII et l’insérer dans les noms de processus n’est pas particulièrement difficile en soi, mais l’idée d’utiliser htop comme moteur de rendu est impressionnante et illustre l’essence même du hacking logiciel.
Respect pour les compétences du développeur : voir des développeurs qui ont le temps et les capacités de créer ce genre de projet fait perdre confiance en ses propres compétences.
Tendance à l’intégration de Doom : il vaut désormais peut-être la peine d’envisager aussi d’intégrer des éléments du quotidien dans Doom. On peut imaginer une liste de tâches ou un calendrier.
Éloge de l’esprit hacker : il est réjouissant de voir des projets de hacking ludiques gagner en popularité, ce qui montre que l’esprit hacker est toujours bien vivant.
Rappel de Bad Apple : cela fait penser à la vidéo de Bad Apple réalisée dans le Gestionnaire des tâches de Windows.
L’avenir de Doom : il est difficile d’imaginer jusqu’où Doom pourra encore être implémenté à l’avenir.