Doom-htop: executando Doom sobre o monitor de processos htop

Implementando DOOM com htop

Como compilar

• Entre no diretório doomgeneric
• Compile com o comando make -j8
• É necessário um arquivo WAD (dados do jogo). Este projeto inclui freedoom1.wad (todos os créditos ao projeto Freedoom). Como alternativa, também é possível baixar e usar a versão clássica gratuita shareware DOOM1.wad

Como executar

• Recomenda-se salvar qualquer trabalho importante antes
• Foi confirmado que funciona bem até em notebooks antigos
• Execute os comandos abaixo:

  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
  

• A ordem de execução de doom-htop e htop não importa
• É necessário sudo para abrir o dispositivo de teclado. Se isso for uma preocupação de segurança, é possível executar sem sudo e apreciar apenas os gráficos
• O -d 1 do htop serve para uma taxa de atualização de 10 FPS. O -s M_VIRT é para ordenar os processos por alocação de memória virtual
• O comando sed é necessário porque o htop por padrão não atualiza o nome dos processos a cada atualização

Como funciona

• O trabalho foi feito a partir de um fork do projeto https://github.com/ozkl/doomgeneric
• Foram adicionados os arquivos main.c, keylogger.c, ascii_stuff.c e feitas algumas modificações
• Foi escrito um conversor simples de imagem para ASCII (a longa cadeia de if em ascii_stuff.c)
• O processo principal do Doom cria processos filhos na mesma quantidade de linhas da imagem ASCII e cria um segmento de memória compartilhada para cada processo
• O processo principal copia cada linha para o segmento de memória do processo correspondente, e cada processo filho lê do seu segmento e sobrescreve argv[0]
• Originalmente a ideia era ordenar os processos pelo uso de CPU, mas isso se mostrou difícil. O nice do Linux também foi considerado, mas foi descartado porque há apenas 19 valores configuráveis pelo usuário
• Surgiu então a ideia de usar a quantidade de memória virtual alocada. Ela é específica para cada processo
• Mesmo que todos os processos filhos aloquem exatamente a mesma memória, os frames aparecem na ordem correta no htop. A suposição é que, em caso de empate, ele ordene pelo momento de criação
• Foi escrito um keylogger simples para abrir o dispositivo de teclado. O jogo continua rodando em segundo plano o tempo todo, independentemente de o htop estar aberto ou não

Plataformas suportadas

• Testado apenas no Ubuntu 22.04
• No WSL e no Arch, o nome do dispositivo de teclado é diferente. É necessário portar

Solução de problemas

1. Se o teclado não funcionar
   • Verifique a macro KEYBOARD_DEVICE em main.c. Ela pode variar conforme a plataforma
   • Use o comando ll /dev/input/by-path e escolha o dispositivo que contenha kbd
2. Se o frame travar
   • O comando sed pode não ter funcionado
   • No htop, vá em F2 -> "Display options" -> marque "Update process names on every refresh"
3. Erro sed: can't read /home/<user>/.config/htop/htoprc: No such file or directory
   • Isso acontece porque o htop nunca foi executado. Abra o htop, feche e execute o sed novamente
4. Se o processo principal do Doom morrer e restarem apenas processos zumbis
   • Execute sudo pkill doom-htop

Melhorias

• Ao mover com as setas, a tela do htop se desloca, o que é incômodo
• Isso pode ser resolvido mudando o foco depois de iniciar o htop (por exemplo, pressionando a tecla a para abrir o menu de seleção de processador)

FAQ

1. Q: Por que você fez isso? A: Porque parecia divertido.

Licença

• Freedoom usa uma licença estilo BSD (veja freedoom-license.txt)
• O restante do código provavelmente está sob GPL

Opinião do GN⁺

• Representar a tela de um jogo 3D com arte ASCII é uma ideia original. Parece também um bom exemplo de como desenhar gráficos em uma tela como a do htop usando C
• É impressionante que não tenha sido apenas uma conversão visual para ASCII, mas uma implementação integrada com o motor real do jogo
• Também vale destacar o bom aproveitamento do projeto doomgeneric, permitindo implementar isso com pouco código
• Abrir diretamente o dispositivo Linux para capturar entrada do teclado pode não funcionar em WSL ou em outros sistemas operacionais. Vale considerar o uso de uma biblioteca de entrada de teclado independente do sistema
• A ideia de usar memória compartilhada para trocar dados dos frames ASCII entre processos pai e filho é interessante. Parece um bom exemplo para estudar IPC
• A ideia de colocar os gráficos ASCII nos nomes dos processos do htop também é criativa. Porém, o htop acaba tendo efeitos colaterais, como a tela se mover por causa das mudanças no nome dos processos. Parece precisar de melhorias
• Embora pareça estar sob licença GPL, isso não está claro. Se o código for reutilizado, é necessário verificar a licença

[GN⁺]

Opiniões do Hacker News

Estes comentários reagem a um projeto que executa o jogo Doom renderizado em ASCII como um processo usando o htop. Os principais pontos são os seguintes:

• Comparação com o PSDoom: Enquanto o PSDoom usa o Doom para gerenciar processos, este projeto faz o oposto: usa um gerenciador de processos para jogar Doom.
• Avaliação técnica: Renderizar em ASCII e colocar isso no nome do processo em si não é tão difícil, mas a ideia de usar o htop como motor de renderização é impressionante e mostra a essência do hacking de software.
• Respeito pela habilidade do desenvolvedor: Ver desenvolvedores com tempo e habilidade para criar projetos assim faz a pessoa perder a confiança nas próprias capacidades.
• Tendência de integração do Doom: Agora talvez também valha pensar em integrar coisas do dia a dia ao Doom. Dá para imaginar lista de tarefas, calendário etc.
• Exaltação do espírito hacker: É bom ver projetos de hacking feitos por diversão ganhando popularidade, e isso mostra que o espírito hacker ainda está vivo.
• Lembra Bad Apple: Faz lembrar o vídeo de Bad Apple implementado no Gerenciador de Tarefas do Windows.
• O futuro do Doom: É difícil imaginar até onde ainda será possível implementar Doom no futuro.