1992年のようにコンパイルする (2014)

 (fabiensanglard.net)
3 ポイント 投稿者 GN⁺ 2024-02-27 | 1件のコメント | WhatsAppで共有
  • 1992年の Wolfenstein 3D のオリジナルソースは現代のシステムにそのままでは適合しないが、DosBox と Borland C++ 3.1 の環境を再現すれば再コンパイルできる
  • 必要な構成は、Wolfenstein 3D のソースコード、DosBox、Borland C++ 3.1、実行用の shareware アセット の4つである
  • ビルド作業では Borland C++ のプロジェクト設定だけでなく、PATH、SIGNON.OBJ、GAMEPAL.OBJ のパスも直接修正する必要がある
  • 初回実行時にグラフィックが崩れる理由は、エンジンにコンパイルされた グラフィックインデックス とアセットファイル内部の位置が互いにずれているためである
  • 再生成した VGA アセットをコピーし、DosBox の aspect correction を有効にすると、1992年の CRT の画面比に近い形で実行できる

1992年のビルド環境を再現

  • Wolfenstein 3D の1992年版オリジナルソースコードは、20年以上を経た現代のシステムではそのまま使いにくいが、当時のツールと実行環境をそろえればコンパイルできる
  • 必要な構成は次の4つである
    • Wolfenstein 3D のソースコード
    • DosBox
    • Borland C++ 3.1
    • Wolfenstein 3D の shareware アセット

DOSドライブとして使うディレクトリを準備

  • ローカルに DOS ドライブのように使うディレクトリを2つ作成する
    • system/c
    • system/a
  • system/a には Borland C++ 3.1 の圧縮ファイルを配置する
  • system/c には Wolfenstein 3D のソースコードと VGA ファイルを配置する
  • 展開後のファイル配置は次のようになる
    • system/a: BCPP31.zip
    • system/c: wolfsrc.zip, vgafiles.zip

DosBoxでコンパイラとソースをインストール

  • DosBox を起動したら、ローカルフォルダを DOS ドライブとしてマウントする
    • ~/system/c を C: にマウント
    • ~/system/a を A: にマウント
  • A:\BCPP31 で install を実行して Borland C++ 3.1 をインストールする
    • 既定設定のままインストールを開始する
    • Microsoft Windows フォルダが見つからないという警告は不要なので Enter で進める
  • C:\ で Wolfenstein 3D のソースインストーラを実行し、既定パス \WOLFSRC を使う

Borland C++ プロジェクトをビルド

  • C:\BORLANDC\BIN\BC.EXE で Borland C++ 3.1 を起動する
  • ..\..\WOLFSRC\WOLF3D.PRJ プロジェクトを開き、ディレクトリを次のように設定する
    • Include Directories: C:\BORLANDC\INCLUDE
    • Library Directories: C:\BORLANDC\LIB
    • Output Directories: OBJ
    • Source Directories: C:\WOLFSRC
  • 最初のビルドでは Cannot find executable TASM エラーが発生する
    • Borland C++ を終了し、PATH=C:\BORLANDC\BIN を設定してから再起動する
  • 次のビルドではリンク段階で Unable to find OBJ file エラーが発生する
    • SIGNON.OBJ と GAMEPAL.OBJ がプロジェクト内で C:\SOURCE\WOLF\ パスに誤って指定されている
    • この2項目をプロジェクトから削除し、WOLFSRC\OBJ\SIGNON.OBJ、WOLFSRC\OBJ\GAMEPAL.OBJ として再追加する
  • その後 Compile -> Build All を実行すればビルドは成功する

実行アセットとグラフィック崩れの原因

  • コンパイルした実行ファイルを動かすには、Wolfenstein 3D の shareware 版または製品版のアセットが必要である
  • shareware をインストールしたあと、コンパイル済みの .EXE をゲームフォルダにコピーして実行すると、画面表示がおかしくなる
  • 原因は、グラフィックファイルを生成する 制作パイプライン とエンジンのアセット参照方法にある
    • Adrian Carmack と Kevin Cloud がグラフィックファイルを作成し、その後 IGRABed ツールでまとめる
    • 出力は VGAHEAD.WL1、VGAGRAPH.WL1、VGADICT.WL1 の3ファイルと、GRE.H、GRE.EQU の2ファイルで構成される
  • VGAHEAD.WL1 は VGAGRAPH.WL1 内のデータ位置を指すインデックスである
    • VGAGRAPH.WL1 には Huffman 圧縮データが保存される
    • VGADICT.WL1 には展開用の Huffman 辞書が入っている
  • GRE.H と GRE.EQU は、エンジンがアセットを名前で参照できるようにするファイルである
    • たとえば L_GUYPIC のような論理名が実際のインデックス値と結び付けられる
    • エンジンは画像インデックスを ハードコード した状態でビルドされる
  • Wolfenstein 3D shareware の公開後、アセットとコードベースが Spears of Destiny とともに変化したため、新たにコンパイルしたゲームのインデックスが既存アセットファイル内の位置と一致しなくなった

VGAアセットの差し替えとアスペクト比補正

  • 解決方法は、ソースコードに含まれる .H、.EQU のインデックスに合うよう再生成した VGA アセット をゲームフォルダにコピーすることである
  • shareware アセットを使う場合は、ファイル拡張子を .WL6 から .WL1 に変えてコピーする必要がある
    • VGADICT.WL6 → VGADICT.WL1
    • VGAGRAPH.WL6 → VGAGRAPH.WL1
    • VGAHEAD.WL6 → VGAHEAD.WL1
  • 差し替え後に WOLF3D.EXE を再実行すると、ゲームは正常に動作する
  • DosBox の既定画面は、1992年に人々が見ていた本来の画面とは異なる
    • VGA フレームバッファは 320x200
    • CRT モニタは 4:3 のアスペクト比なので、出力時には縦方向に引き伸ばされて見えていた
  • DosBox 設定の [render] で aspect=false を aspect=true に変更すると、アスペクト比補正が適用される
  • アスペクト比補正まで適用すれば、Wolfenstein 3D を当時の CRT 表示方式に近い見た目で実行できる

関連記事

1件のコメント

 
GN⁺ 2024-02-27
Hacker Newsのコメント

  • 文末で触れられているWolfenstein 3D本を強くおすすめする。技術的な内容なのに堅苦しくも退屈でもなく、壁テクスチャのスケーリング用に展開した64個の関数、スプライトを「横向きに」保存する方式、奇妙なグラフィックカードの扱い方、そもそもゲームらしく見せるためにグラフィックモードをハックする方法など、昔ながらの最適化がたくさん出てくる

    • おすすめありがとう。ゲームエンジンに関する431ページのPDFを今ダウンロードしたところで、John Carmackの序文まで入っている
    • この本のこと？ https://fabiensanglard.net/Game_Engine_Black_Book/index.php
      まだ出ていないように見えるけど、合ってる？
    • まったく同感。こんな本があることも知らなかったけれど、Wolfenstein 3D本とDoom本の両方を本当に楽しく読んだ。彼がQuake/i586本を書かないらしいのが残念だ
    • 続編のDoom本もとても読みやすくて素晴らしい

  • レトロなシステムの良いところは、ツールさえそろえば再ビルドできることだ。最近、遊び半分で古いUplinkを再コンパイルしたが、必要だったのはVisual Studio 6.0だけで、開発アーカイブにはビルドに必要な依存関係がすべて入っていた
    依存関係を合わせるのに1時間ほどかかったが、最終的には成功してゲームもちゃんと動いた。細かな不具合も直し、あちこちに小さな改善も入れた。今どきのソフトウェアのことを思うと本当に狂気じみている

    • それはLinuxのパッケージ管理がひどい場合により当てはまる気がする。私が見てきた商用の組み込み/Windows界隈では、たいてい依存関係は thirdparty/ フォルダにベンダリングされていて、使うツールチェーンも固定されているので、セットアップは常に再現可能だった
    • 今では必要なもののかなりの部分は、単に適切なバージョンのUnityやUnrealをインストールすることだ。Unity以前の時代については、たしかにその通り
    • Uplinkのソースコードが公開されているとは知らなかった。素晴らしいゲームだ

  • Borland Turbo C++ でプログラミングを覚えた。あの頃が恋しい理由の一つは、複雑そうに見えることをとても簡単にできた点だ。図形描画関数を呼ぶだけで画面に絵が出て、図形を描いたあと少し違う図形に xor 関数を呼べばアニメーションまで作れた
    友人たちとこうした手法でFinal Fantasy風のゲームを作り、手作りスプライトと画面単位のマップ、端まで行くと隣のマップへ移るワールド、歩くたびに乱数で1が出たら戦闘に入る仕組みまで作った。手間はかかったが高校生には本当に楽しく、今のように最初からSFML、ActiveX、OpenGLを学ばなくても、ただ circle を呼べばよかったのが大きかった

    • 子どもが簡単な図形プログラミングをできる環境なら、今でもそういうものはある気がする。違いは、「プロ向けツール」と「子ども/入門者向けツール」の分岐がずっと大きくなったことで、Turbo C++ や私の時代のTurbo Pascalはその両方に近かった
    • 子どもの頃にBorland Turbo C++ と学習資料に触れられたのは少しうらやましい。私は地元のコンピュータ雑誌のレビューを読むくらいしかできず、たとえコピーを手に入れられても、読む資料なしでは何をすればいいのかわからなかっただろう。当時の英語力では、資料があってもどこまで理解できたか怪しい
    • 現代の2Dグラフィックスはフレームバッファにピクセルを打つ方式ではなく、テクスチャやサーフェスがシステムの基本要素で、合成は別の段階で処理される。だから「単純なスプライト」を作るのはむしろ簡単になっていて、合成済みサーフェスはハードウェアスプライトをより一般化したものと考えればいい
    • 懐かしの conio.h とBorlandのBGI graphics.h を思い出す。今ならSDLがある程度その役割を果たすが、そこまで単純ではない
    • Borland Turbo C++ は今でも私のいちばん好きなIDEで、圧倒的な1位だ

  • ここで何年にもわたって何度も言及されているのを見て、数か月前についにMasters of Doomを読んだが、素晴らしい本だった。当時彼らが作っていたゲームは遊ぶこと自体もものすごく魅力的だったが、振り返ってみると、あまり多くを持たない若い開発者が数人で何を作れたかという点のほうが、さらに大きな刺激を与えてくれる

    • Romeroが最近回想録Doom Guyを出したそうだが、読んだ人はいるだろうか。良い本なのか知りたい

  • DOSのテキストベースUIが本当に恋しい。1997年ごろまで使っていた頼もしいPS/2を思い出す

    • ターミナルでMidnight Commanderくらいなら使える

  • Cドライブへのインストールなんて、ぜいたくだった！ ハードディスクがなかったのでAドライブとBドライブの間でフロッピーをひたすら差し替え、コンパイラの入れ替え済みパーツを何度も要求された。それでも私たちは楽しんでいた。今の子どもたちは、こういう話をしても信じない

    • 1992年には8.9MBの5.25インチ・ダブルハイトHDDがあり、5.25インチ360KBのフロッピードライブも2台あった。友人の720KBディスクドライブと30MB HDD付きMacがうらやましかったが、そのシステムは私のPCのたぶん6倍くらい高かったはずだ
    • 1982年ではなく1992年だ

  • Borland C++ は本当に素晴らしかった。C++コンパイラ、標準ライブラリ、デバッガ付きIDEが約5MBに収まり、黄色い文字に青い背景という居心地のいいBorlandのカラーパレットまで備えていた

    • C++チュートリアル入りの印刷マニュアルも付属していた。昔それでC++を学んだ
    • OWLもかなり良かった
    • Zortechのほうがずっと良かった

  • BorlandのMS-DOS IDEは甘い思い出だ

    • こういうノスタルジーがあるならFree Pascalを試してみる価値がある。オープンソースのPascal/Delphiクローンで、青いDOS版Turbo Pascalエディタのクローンも入っているので、あの雰囲気を味わえる
      今年のAdvent of Codeの何日分かで使ってみたが、ノスタルジーはすぐに消えた。現代的な環境に慣れた状態では、IDEの制約やPascalの冗長さは、日常的に使うにはそれほど「楽しい」ものではなかった。それでも思い出が甘いのは確かだ
    • RHIDEは最後の更新が23年前とはいえ、まだソースコードは残っているはずだ。この手のターミナルモードGUIを実装する際の本当の問題は、Unix/Linuxターミナルが、MS-DOSのテキストモードプログラムの機能をすべて提供しないターミナル標準に縛られていたことだ
      とくにAltキー単独入力、Alt+文字の組み合わせ、Ctrl+Shift+左右矢印キーを認識できない
    • 昔の本棚スペースにTurbo Cのマニュアルが入った箱をまだ保管している

  • 関連記事: Let’s compile like it’s 1992 (2014) - https://news.ycombinator.com/item?id=13750097 - 2017年2月、コメント80件

  • アーカイブを開くのに問題があった。wolfsrc.zip で End-of-central-directory signature not found エラーが出て、zipファイルではないか、複数ディスクに分割されたアーカイブの一部かもしれないと言われた