3 điểm bởi GN⁺ 2024-02-27 | 1 bình luận | Chia sẻ qua WhatsApp
  • Mã nguồn gốc của Wolfenstein 3D năm 1992 không còn khớp ngay với các hệ thống hiện đại, nhưng vẫn có thể biên dịch lại nếu tái tạo môi trường DosBoxBorland C++ 3.1
  • Các thành phần cần thiết gồm mã nguồn Wolfenstein 3D, DosBox, Borland C++ 3.1 và tài nguyên shareware để chạy
  • Trong quá trình build, không chỉ cần chỉnh thiết lập dự án Borland C++ mà còn phải sửa trực tiếp đường dẫn PATH, SIGNON.OBJ, GAMEPAL.OBJ
  • Lý do đồ họa bị lỗi khi chạy lần đầu là vì chỉ mục đồ họa được biên dịch vào engine không còn khớp với vị trí bên trong các tệp tài nguyên
  • Có thể chạy game với tỷ lệ gần với màn hình CRT năm 1992 bằng cách sao chép lại các tài nguyên VGA đã được tái tạo và bật aspect correction trong DosBox

Tái tạo môi trường build năm 1992

  • Mã nguồn gốc năm 1992 của Wolfenstein 3D rất khó dùng nguyên trạng trên các hệ thống hiện đại sau hơn 20 năm, nhưng vẫn có thể biên dịch nếu dùng đúng công cụ và môi trường chạy của thời đó
  • Cần chuẩn bị bốn thành phần sau
    • Mã nguồn Wolfenstein 3D
    • DosBox
    • Borland C++ 3.1
    • Tài nguyên shareware của Wolfenstein 3D

Chuẩn bị thư mục dùng như ổ đĩa DOS

  • Tạo 2 thư mục cục bộ để dùng như ổ đĩa DOS
    • system/c
    • system/a
  • Tải tệp nén Borland C++ 3.1 vào system/a
  • Tải mã nguồn Wolfenstein 3D và các tệp VGA vào system/c
  • Sau khi giải nén, bố cục tệp được sắp xếp như sau
    • system/a: BCPP31.zip
    • system/c: wolfsrc.zip, vgafiles.zip

Cài compiler và mã nguồn trong DosBox

  • Sau khi chạy DosBox, mount các thư mục cục bộ thành ổ đĩa DOS
    • Mount ~/system/c thành C:
    • Mount ~/system/a thành A:
  • Chạy install trong A:\BCPP31 để cài Borland C++ 3.1
    • Giữ nguyên cấu hình mặc định và bắt đầu cài đặt
    • Cảnh báo không tìm thấy thư mục Microsoft Windows là không cần thiết, chỉ cần nhấn Enter để bỏ qua
  • Tại C:\, chạy trình cài đặt mã nguồn Wolfenstein 3D và dùng đường dẫn mặc định \WOLFSRC

Build dự án Borland C++

  • Chạy Borland C++ 3.1 bằng C:\BORLANDC\BIN\BC.EXE
  • Mở dự án ..\..\WOLFSRC\WOLF3D.PRJ và đặt thư mục như sau
    • Include Directories: C:\BORLANDC\INCLUDE
    • Library Directories: C:\BORLANDC\LIB
    • Output Directories: OBJ
    • Source Directories: C:\WOLFSRC
  • Ở lần build đầu tiên sẽ xuất hiện lỗi Cannot find executable TASM
    • Thoát Borland C++, đặt PATH=C:\BORLANDC\BIN rồi chạy lại
  • Ở lần build tiếp theo sẽ xuất hiện lỗi Unable to find OBJ file ở bước liên kết
    • SIGNON.OBJGAMEPAL.OBJ đang bị chỉ tới sai đường dẫn C:\SOURCE\WOLF\ trong dự án
    • Xóa hai mục này khỏi dự án rồi thêm lại bằng WOLFSRC\OBJ\SIGNON.OBJ, WOLFSRC\OBJ\GAMEPAL.OBJ
  • Sau đó chạy Compile -> Build All thì build sẽ thành công

Tài nguyên chạy và nguyên nhân lỗi đồ họa

  • Muốn chạy file thực thi đã biên dịch thì cần tài nguyên của Wolfenstein 3D bản shareware hoặc bản đầy đủ
  • Sau khi cài shareware, nếu sao chép file .EXE đã biên dịch vào thư mục game rồi chạy thì màn hình sẽ hiển thị bất thường
  • Nguyên nhân nằm ở pipeline tạo nội dung cho các tệp đồ họa và cách engine truy cập tài nguyên
    • Adrian Carmack và Kevin Cloud tạo các tệp đồ họa rồi đóng gói bằng công cụ IGRABed
    • Đầu ra gồm 3 tệp VGAHEAD.WL1, VGAGRAPH.WL1, VGADICT.WL1 và 2 tệp GRE.H, GRE.EQU
  • VGAHEAD.WL1 là chỉ mục trỏ tới vị trí dữ liệu bên trong VGAGRAPH.WL1
    • VGAGRAPH.WL1 lưu dữ liệu nén Huffman
    • VGADICT.WL1 chứa từ điển Huffman dùng để giải nén
  • GRE.HGRE.EQU là các tệp giúp engine truy cập tài nguyên theo tên
    • Ví dụ, tên logic như L_GUYPIC được ánh xạ tới giá trị chỉ mục thực tế
    • Engine được build với các chỉ mục hình ảnh hardcode sẵn bên trong
  • Sau khi Wolfenstein 3D shareware phát hành, tài nguyên và codebase tiếp tục thay đổi cùng với Spear of Destiny, khiến chỉ mục của bản game biên dịch mới không còn khớp với vị trí trong các tệp tài nguyên cũ

Thay thế tài nguyên VGA và hiệu chỉnh tỷ lệ hiển thị

  • Cách giải quyết là sao chép các tài nguyên VGA đã được tái tạo vào thư mục game sao cho khớp với các chỉ mục .H, .EQU đi kèm trong mã nguồn
  • Nếu dùng tài nguyên shareware thì cần đổi phần mở rộng tệp từ .WL6 sang .WL1 trước khi sao chép
    • VGADICT.WL6VGADICT.WL1
    • VGAGRAPH.WL6VGAGRAPH.WL1
    • VGAHEAD.WL6VGAHEAD.WL1
  • Sau khi thay thế, chạy lại WOLF3D.EXE thì game sẽ hoạt động bình thường
  • Màn hình mặc định của DosBox khác với những gì người dùng thấy vào năm 1992
    • Framebuffer VGA là 320x200
    • Màn hình CRT có tỷ lệ 4:3, nên khi hiển thị hình ảnh sẽ bị kéo dãn theo chiều dọc
  • Trong cấu hình DosBox, nếu đổi aspect=false thành aspect=true trong mục [render] thì hiệu chỉnh tỷ lệ sẽ được áp dụng
  • Khi áp dụng cả hiệu chỉnh tỷ lệ, Wolfenstein 3D sẽ chạy với hình ảnh gần hơn với cách nó từng được hiển thị trên màn CRT thời đó

1 bình luận

 
GN⁺ 2024-02-27
Các ý kiến trên Hacker News
  • Rất khuyến nghị cuốn sách Wolfenstein 3D được nhắc đến ở cuối bài. Dù là nội dung kỹ thuật, sách không hề khô khan hay nhàm chán, và có rất nhiều tối ưu kiểu xưa như 64 hàm được trải sẵn để scale texture tường, cách lưu sprite “theo chiều ngang”, xử lý các card đồ họa kỳ quặc, hay hack chế độ đồ họa ngay từ đầu để trông giống game

    • Cảm ơn vì gợi ý. Tôi vừa tải xuống PDF 431 trang về game engine, có cả lời tựa của John Carmack
    • Có phải cuốn này không? https://fabiensanglard.net/Game_Engine_Black_Book/index.php
      Trông như chưa phát hành, đúng không?
    • Hoàn toàn đồng ý. Tôi còn không biết có những cuốn sách như vậy, nhưng đã đọc cả sách Wolfenstein 3D lẫn Doom rất thích. Tiếc là ông ấy sẽ không viết cuốn Quake/i586
    • Cuốn tiếp theo, sách Doom, cũng đọc rất hay
  • Điểm hay của các hệ thống retro là chỉ cần gom đủ công cụ là có thể build lại. Gần đây tôi đã thử biên dịch lại game Uplink cũ cho vui; thứ cần thiết chỉ là Visual Studio 6.0, và archive phát triển đã chứa sẵn mọi dependency cần để build
    Mất khoảng một giờ để khớp dependency, nhưng cuối cùng cũng thành công và game chạy tốt. Tôi còn sửa vài lỗi nhỏ và thêm một số cải tiến lặt vặt. Nghĩ đến việc đụng vào phần mềm ngày nay thì đúng là điên rồ

    • Điều đó có vẻ đúng hơn với trường hợp quản lý gói trên Linux lộn xộn. Phía embedded thương mại/Windows mà tôi từng thấy thường vendor các dependency vào thư mục thirdparty/, và cố định cả toolchain đang dùng, nên thiết lập luôn tái lập được
    • Ngày nay phần lớn những gì cần làm chỉ là cài đúng phiên bản Unity hoặc Unreal. Với thời kỳ trước Unity thì nhận xét đó chắc chắn đúng
    • Tôi không biết mã nguồn Uplink đã được công khai. Game tuyệt vời
  • Tôi học lập trình bằng Borland Turbo C++. Một trong những lý do tôi nhớ thời đó là những việc trông có vẻ phức tạp lại làm được quá dễ. Chỉ cần gọi hàm hình học là vẽ được hình lên màn hình, và sau khi vẽ một hình, gọi hàm xor với một hình hơi khác là có thể tạo animation
    Tôi cùng bạn bè đã dùng kỹ thuật này để làm một game giống Final Fantasy, với sprite tự làm, map theo từng màn hình, thế giới chuyển sang map liền kề khi đi tới mép, và cơ chế vào trận nếu mỗi bước đi ra số tự nhiên 1. Dù khá phiền phức, với học sinh cấp ba thì cực kỳ vui, và điểm lớn là thay vì ngay từ đầu phải học SFML, ActiveX, OpenGL như ngày nay, chỉ cần gọi circle

    • Nếu muốn tìm môi trường cho trẻ em lập trình các hình đơn giản thì chắc hiện nay vẫn có. Khác biệt là “công cụ cho chuyên gia” và “công cụ cho trẻ em/người mới học” đã tách biệt hơn nhiều, còn Turbo C++ hay Turbo Pascal thời tôi thì gần với cả hai
    • Tôi hơi ghen tị vì hồi nhỏ bạn có thể tiếp cận Borland Turbo C++ và tài liệu học. Tôi chỉ đọc được các bài review trên tạp chí máy tính địa phương, và kể cả có kiếm được bản sao thì nếu không có tài liệu đọc, tôi cũng không biết phải làm gì. Với trình độ tiếng Anh khi đó, dù có tài liệu cũng không rõ tôi hiểu được bao nhiêu
    • Đồ họa 2D hiện đại không phải là chấm pixel vào framebuffer; texture hoặc surface mới là thành phần cơ bản của hệ thống, còn compositing được xử lý ở một bước riêng. Vì vậy việc tạo “sprite đơn giản” thực ra đã dễ hơn, và có thể xem surface đã được compositing là một dạng tổng quát hơn của hardware sprite
    • Nhớ conio.h ngày xưa tốt đẹp và BGI graphics.h của Borland. Ngày nay SDL phần nào đóng vai trò đó, nhưng không đơn giản đến vậy
    • Borland Turbo C++ đến giờ vẫn là IDE tôi thích nhất, bỏ xa mọi cái khác
  • Sau khi thấy được nhắc đến nhiều lần ở đây trong mấy năm, vài tháng trước cuối cùng tôi đã đọc Masters of Doom, và đó là một cuốn sách xuất sắc. Những game họ làm thời đó tự thân đã cực kỳ thú vị để chơi, nhưng nhìn lại thì việc vài lập trình viên trẻ với rất ít nguồn lực có thể tạo ra những gì còn truyền cảm hứng hơn

    • Romero gần đây có ra hồi ký Doom Guy; không biết có ai đã đọc chưa. Tôi muốn biết sách có ổn không
  • Tôi thật sự nhớ UI dựa trên văn bản của DOS. Nhớ chiếc PS/2 đáng tin cậy mà tôi dùng mãi đến khoảng năm 1997

    • Ít nhất vẫn có thể dùng Midnight Commander trong terminal
  • Cài vào ổ C ư, xa xỉ quá! Không có ổ cứng nên phải liên tục đổi đĩa mềm giữa ổ A và B, và trình biên dịch cứ đòi phần đã bị thay ra. Dù vậy chúng tôi vẫn thấy vui. Bọn trẻ ngày nay nghe kể mấy chuyện này cũng không tin đâu

    • Năm 1992 tôi có một ổ cứng double-height 5,25 inch dung lượng 8.9MB, cùng hai ổ đĩa mềm 5,25 inch 360KB. Tôi ghen tị với chiếc Mac của bạn tôi có ổ đĩa 720KB và ổ cứng 30MB, nhưng hệ thống đó có lẽ đắt gấp khoảng 6 lần PC của tôi
    • 1992, không phải 1982
  • Borland C++ thật sự xuất sắc. Một IDE có compiler C++, thư viện chuẩn và debugger nằm gọn trong khoảng 5MB, kèm bảng màu Borland ấm cúng với chữ vàng trên nền xanh dương

    • Nó còn đi kèm sách hướng dẫn in giấy có tutorial C++. Tôi đã học C++ bằng cuốn đó ngày xưa
    • OWL cũng khá tốt
    • Zortech hay hơn nhiều
  • Các MS-DOS IDE của Borland là những ký ức ngọt ngào

    • Nếu có nỗi hoài niệm này thì đáng thử Free Pascal. Đây là một clone Pascal/Delphi mã nguồn mở, có cả clone trình soạn thảo Turbo Pascal DOS màu xanh dương, cho bạn đúng cảm giác mong muốn
      Tôi đã dùng nó cho vài ngày Advent of Code năm nay, nhưng cảm giác hoài niệm nhanh chóng biến mất. Khi đã quen với môi trường hiện đại, các giới hạn của IDE và sự dài dòng của Pascal không “vui” để dùng hằng ngày. Dù vậy ký ức chắc chắn vẫn ngọt ngào
    • RHIDE tuy lần cập nhật cuối đã 23 năm trước, nhưng có lẽ mã nguồn vẫn còn. Vấn đề thật sự khi triển khai kiểu GUI chế độ terminal này là terminal Unix/Linux bị mắc kẹt trong các chuẩn terminal không cung cấp đủ chức năng của chương trình text mode trên MS-DOS
      Đặc biệt là không nhận được nhấn riêng phím Alt, tổ hợp Alt+chữ, hay Ctrl+Shift+mũi tên trái/phải
    • Tôi vẫn còn giữ một thùng chứa manual Turbo C ở chỗ kệ sách cũ
  • Bài liên quan: Let’s compile like it’s 1992 (2014) - https://news.ycombinator.com/item?id=13750097 - tháng 2/2017, 80 bình luận

  • Tôi gặp vấn đề khi mở archive. Với wolfsrc.zip có lỗi End-of-central-directory signature not found, và thông báo rằng đó không phải file zip hoặc có thể là một phần của archive chia nhiều đĩa