Doom-htop: Chạy Doom trên công cụ giám sát tiến trình htop

 (github.com/0x0mer)
2 điểm bởi GN⁺ 2024-04-22 | 1 bình luận | Chia sẻ qua WhatsApp
  • doom-htop là một dự án thử nghiệm dùng danh sách tiến trình của htop như đầu ra đồ họa để hiển thị màn hình game dòng Doom dưới dạng ASCII
  • Để chạy cần có tệp dữ liệu game WAD; kho lưu trữ đã bao gồm freedoom1.wad, còn classic shareware DOOM1.wad được hướng dẫn tải riêng
  • Cách hoạt động là tiến trình Doom tạo các tiến trình con tương ứng với số dòng màn hình, mỗi tiến trình ghi một dòng nhận từ bộ nhớ chia sẻ vào argv[0] của chính nó để dựng khung hình trong vùng tên tiến trình của htop
  • Cần cấu hình htop để cập nhật tên tiến trình mỗi lần; dùng -d 1 nhằm đạt tần suất làm mới khoảng 10 FPS và -s M_VIRT để sắp xếp theo bộ nhớ ảo
  • Nhập liệu bàn phím dùng kiểu keylogger đơn giản mở thiết bị bàn phím, nên có thể cần sudo; mới chỉ được kiểm thử trên Ubuntu 22.04, còn WSL và Arch cần điều chỉnh đường dẫn thiết bị

Mục tiêu dự án và hình thức chạy

  • doom-htop là dự án được tạo ra để kiểm tra liệu htop có thể dùng để render đồ họa game video cổ điển hay không
  • Kết quả là hiển thị Doom như một video ASCII trên danh sách tiến trình của htop
  • Dự án fork từ ozkl/doomgeneric, và các phần nặng liên quan đến việc chạy Doom do dự án đó đảm nhiệm

Build và dữ liệu game cần thiết

  • Build được thực hiện trong thư mục doomgeneric bằng make -j8
cd doomgeneric
make -j8
  • Để chạy cần có tệp dữ liệu game WAD
    • Kho lưu trữ đã bao gồm freedoom1.wad, phần ghi công thuộc về The Freedoom project
    • Phiên bản classic free shareware DOOM1.wad có thể tải từ Doom Wiki
    • DOOM1.wad không được đưa vào vì tác giả không chắc việc tải lên GitHub có hợp pháp hay không

Cách chạy và cấu hình htop

  • Có hướng dẫn lưu các công việc quan trọng trước khi chạy; môi trường kiểm thử là Lenovo ThinkPad T430s 12 năm tuổi, RAM 8GB, Intel Core i7-3520M @ 2.90GHz, Ubuntu 22.04 và hoạt động bình thường
  • Lệnh chạy mặc định như sau
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
  • Chạy doom-htop hay htop trước đều được
  • sudo chỉ cần để mở thiết bị bàn phím
    • Nếu chạy không có sudo, việc nhập liệu sẽ khó nhưng vẫn có thể xem màn hình
  • htop -d 1 là thiết lập nhằm làm mới ở 10 FPS
  • htop -s M_VIRT là thiết lập để sắp xếp tiến trình theo lượng bộ nhớ ảo được cấp phát, giúp các tiến trình liên quan được gom lại dễ nhìn
  • Nếu thứ tự sắp xếp không khớp, có thể điều chỉnh giá trị PROCS_MALLOC_SIZE trong main.c
  • Lệnh sed cần thiết vì mặc định htop không cập nhật tên tiến trình mỗi lần

Cách hoạt động bên trong

  • Kho lưu trữ chủ yếu thêm ba tệp vào doomgeneric hiện có
    • main.c
    • keylogger.c
    • ascii_stuff.c
  • ascii_stuff.c chứa một chuỗi câu lệnh if dài do một bộ chuyển đổi image-to-ASCII đơn giản tạo ra
  • Tiến trình Doom chính dùng fork để tạo số tiến trình tương ứng với số dòng của ảnh đã chuyển đổi sang ASCII
  • Tiến trình chính tạo segment bộ nhớ chia sẻ với từng tiến trình con và sao chép từng dòng của ảnh vào segment bộ nhớ của tiến trình tương ứng
  • Mỗi tiến trình con sao chép nội dung từ segment của mình rồi ghi đè lên argv[0]
  • htop cập nhật giá trị argv[0] được hiển thị dưới dạng tên tiến trình, qua đó hiển thị từng dòng của màn hình

Ý tưởng sắp xếp và xử lý nhập liệu

  • Ý tưởng ban đầu là sắp xếp theo mức sử dụng CPU và tạo các tiến trình tiêu thụ một mức CPU nhất định, nhưng việc triển khai khó
  • Giá trị nice của Linux cũng được cân nhắc, nhưng người dùng thông thường chỉ có 19 giá trị khả dụng nên được cho là không đủ để tạo đồ họa tốt hơn
  • Cuối cùng, tác giả dùng lượng bộ nhớ ảo được cấp phát, vì cho rằng có thể điều chỉnh khá cụ thể theo từng tiến trình
  • Ngay cả khi mọi tiến trình fork cấp phát cùng một lượng bộ nhớ, trên hệ thống kiểm thử htop vẫn hiển thị khung hình đúng thứ tự
    • Tác giả phỏng đoán khi hòa nhau, có thể tiến trình được sắp xếp theo thời điểm tạo
    • Tuy nhiên không chắc trên hệ thống khác sẽ hoạt động thế nào, nên không phụ thuộc vào cùng một giá trị
  • Phím bấm được xử lý bằng một keylogger đơn giản mở thiết bị bàn phím
    • Nhờ cách này, game vẫn tiếp tục chạy trong nền ngay cả khi htop không mở

Nền tảng và xử lý sự cố

  • Việc kiểm thử chỉ được thực hiện trên Ubuntu 22.04
  • Trên WSL và Arch, tên thiết bị bàn phím khác nhau và cần port lại
  • Nếu bàn phím không hoạt động, cần kiểm tra giá trị #define KEYBOARD_DEVICE trong main.c
    • Có hướng dẫn tìm và chọn mục chứa kbd trong /dev/input/by-path
  • Nếu khung hình bị đứng, có thể lệnh sed chưa được áp dụng
    • Có thể thiết lập thủ công trong htop bằng cách vào F2 → “Display options” → chọn “Update process names on every refresh”
  • Lỗi không có ~/.config/htop/htoprc có thể xảy ra khi chưa từng chạy htop
    • Chỉ cần chạy htop rồi thoát, sau đó chạy lại lệnh sed
  • Nếu tiến trình Doom chính bị crash và để lại nhiều tiến trình zombie, dọn dẹp bằng lệnh sau
sudo pkill doom-htop

Việc còn lại và giấy phép

  • htop sẽ di chuyển màn hình khi dùng phím mũi tên, có thể gây bất tiện khi điều khiển game
    • Một cách né đơn giản được đề xuất là sau khi bắt đầu game, nhấn a để chuyển focus sang menu chọn processor
  • Lý do tạo ra dự án là funny
  • Freedoom được phân phối theo giấy phép kiểu BSD trong freedoom-license.txt ở thư mục chính
  • Phần mã còn lại được ghi chú là có vẻ theo GPL

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-04-22
Các ý kiến trên Hacker News

  • Nghĩ lại thì việc render “video” thành ASCII rồi đưa vào tên tiến trình trông cũng khá dễ
    Nó giống các dự án đồ chơi chạy trên DNS, và README cũng nói phần lớn công việc là do dự án khác làm, nên có thể không có vẻ gì đặc biệt
    Nhưng mặt khác, có lẽ tôi chưa từng nghĩ có thể xem htop như một rendering engine cho thứ gì đó, nên đây thật sự là một màn hack phần mềm đáng ngạc nhiên và ấn tượng

    • Nghĩ qua thì có vẻ dễ, nhưng thực tế để có được độ tương phản tốt và hiệu năng thì không hề tầm thường
      Chỉ cần nhìn libaa hay libcaca cũng thấy có những ví dụ đã dành hàng trăm giờ cho chủ đề này
    • Về mặt khái niệm có thể dễ hiểu, nhưng phần triển khai trông khá khó

  • Có lẽ giống PSDoom[1] đảo ngược
    Bài này là chơi Doom bằng trình quản lý tiến trình, còn PSDoom là quản lý tiến trình bằng Doom
    [1]: https://psdoom.sourceforge.net

    • Tôi định viết là muốn thấy chiều ngược lại, nhưng cũng không ngạc nhiên khi nó đã tồn tại
      Còn có video port để chạy trên Linux hiện nay: https://youtu.be/Pf7rpde49NU
      Tuy vậy sẽ hay hơn nếu nó thực sự hữu ích hơn một chút như một bản thay thế top. Kích thước quái vật dựa trên mức dùng bộ nhớ, độ hung hãn dựa trên mức dùng CPU, các phòng chia theo từng người dùng, đồng thời hiển thị được quan hệ giữa thread và tiến trình cha/con
      Các tiến trình đang ngủ tất nhiên sẽ ngủ, còn tiến trình zombie có thể bị đóng băng tại chỗ trong không gian hoặc trong suốt để đi xuyên qua được. Vũ khí thì ánh xạ với các tín hiệu kill
      Còn nhiều thứ có thể thêm, nhưng như vậy sẽ ngày càng xa Doom
    • Dùng cùng với rm -rf chắc sẽ thú vị

  • Tôi thật sự tò mò không biết người ta lấy đâu ra thời gian để làm những thứ như thế này
    Càng thấy những thứ tuyệt vời như vậy, tôi càng mất dần niềm tin vào năng lực của mình
    Có người nói là tận dụng công việc trước đó, render lại thành ASCII rồi ánh xạ vào các tiến trình, nhưng như thế tuyệt đối không phải là ít việc
    Tôi tự hỏi mất bao lâu, và dù đã ở trong ngành này khá lâu, tôi vẫn có cảm giác mình chẳng biết gì. Rất ngầu, nhưng khiến tôi thấy mình cực kỳ ngốc

    • Cảm ơn những lời ấm áp, và bạn không cần tự trách mình quá đâu
      Rất có thể bạn biết nhiều hơn rất nhiều so với bạn nghĩ
      Công việc này được làm trong trọn một cuối tuần cộng khoảng một ngày, rồi thêm vài ngày làm lắt nhắt khi có thời gian
      Như tôi đã viết ở đâu đó trong phần bình luận và trong README, phần khó là làm cho Doom dễ port hơn thì dự án fork doom-generic đã làm sẵn: https://github.com/ozkl/doomgeneric
    • Làm việc 8 tiếng một ngày và đi lại 1 tiếng thì vẫn còn 15 tiếng
      Dù phải ăn, ngủ, tắm rửa và làm đủ thứ khác, nhưng nếu không bận tâm đến mấy việc đó thì vẫn nguyên 15 tiếng
      3 năm là đủ thời gian để làm
      Giờ tôi phải hoàn tất nốt raycaster cho 6502
    • Cảm giác này quen thuộc quá
      Nó giống như phiên bản lập trình viên của việc nhìn ảnh nhà cửa hoàn hảo bạn bè đăng trên Instagram rồi tự bào mòn lòng tự trọng
      Hầu hết mọi người thỉnh thoảng đều cảm thấy vậy, và cũng có cách đối phó, nhưng đó là tác dụng phụ rất bình thường khi ở quanh những người thông minh
    • Mỗi lần thấy những thứ như thế này lại làm tôi nhớ về thời chưa có con

  • Trào lưu “nhét Doom vào thứ gì đó” có cảm giác gần như đã đạt đến giai đoạn hoàn thiện, và giờ đã đến lúc bắt đầu nhét các thứ thường ngày vào trong Doom
    Cứ tưởng tượng danh sách Todo hay lịch nằm trong Doom

    • Nói nghiêm ngặt thì đó không phải danh sách Todo hay lịch trong Doom, mà là Doom chạy trong danh sách Todo hoặc lịch
      Về phía ứng dụng Todo thì đã có Doom được render bằng checkbox rồi[1], nên việc tích hợp nó vào ứng dụng Todo có thể để lại như bài tập cho độc giả
      [1]: https://healeycodes.github.io/doom-checkboxes/
    • Nếu bạn cảm thấy trào lưu “nhét Doom vào thứ gì đó” sắp kết thúc, có lẽ bạn còn khá mới trong thế giới này
    • Tôi cũng nghĩ y hệt khi thấy “chim chơi DOOM”

  • Tôi tình cờ thấy dự án này khoảng một tuần trước và đã đăng lên đây nhưng không có phản hồi
    Giờ thấy nó lên trang nhất thì thật vui, và tôi thích việc những dự án hack vui là chính như thế này được đưa lên

  • Một màn hack xuất sắc
    Thấy tinh thần hacker vẫn còn sống khiến tôi rất vui

  • Đôi khi con người đưa công nghệ đi quá xa, nhưng lần này thì không phải trường hợp đó

  • Làm tôi nhớ đến Bad Apple chạy trong Windows Task Manager
    https://youtu.be/sBeI30ccb6g

  • Một sự điên rồ thuần khiết và tuyệt vời. A+

  • Không thể tưởng tượng nổi sau này trò chơi này còn sẽ chạy ở đâu nữa