コグノスケ

何もない組み込み環境でDOOMを動かす - その1 - 準備編

DOOMというFPS（First Person Shooter、一人称視点のシューティングゲーム）があります。1993年にid Softwareが開発したロングセラーシリーズです。オリジナルのid Softwareによる実装も2012年にオープンソースになりました（リポジトリへのリンク）。

日本ではそれほどでもない気がしますが、海外ではDOOMの人気は絶大で海外エンジニアの間ではゲーム機ではない電子機器（プリンタ、カメラ、ATMまで）でDOOMを動作させる改造が非常に人気のようです。

DOOM移植の良いところとしては、3D描画のゲームなので画面が派手で目を引きます。それでいて昔のゲームなので、しょぼいスペックの機器でもそこそこ動きます。操作せずに放っておいてもデモが実行される点も素晴らしいです。

今回はオリジナルのDOOMではなくprboom2（リポジトリへのリンク）というクローン実装を使います。prboom2はLinuxで簡単に動作確認できて楽です。いいですね。

IWADファイル

DOOMはゲームエンジンなので実行時にはゲームデータを指定しなければなりません。ゲームデータは*.WADというファイル（Where's All Dataの略らしい）に格納されていて、オリジナルDOOMのWADファイルのことをIWAD（Internal WAD）と呼ぶようです。IWADはDOOMの製品版に付属しているはずです、見たことがないから知らないですけど。本来はオリジナルDOOMを購入しDOOM.WADを持ってくるべきですが、手に入れる手段がなさそうです……。

ネット検索するとIWADを公開しているサイトがあるのでどうにかして手に入れてください。Doom Wiki（リンク）にDOOM.WADのMD5 hashが掲載されているので、入手したIWADファイルがどのバージョンか（あるいは壊れていないか）確認しましょう。

今回はIWADファイルはDOOM.WAD、バージョン1.8のもので試します。

Linuxで動作確認

まずは普通に動かしてみます。ビルドは簡単でbootstrapとconfigureを実行してmakeするだけです。SDLがインストールされていない環境の場合はlibsdl2-devのインストールが必要かもしれません。

$ cd prboom2
$ ./bootstrap
$ ./configure
$ make

$ ./src/prboom -iwad DOOM.WAD

DOOM同様prboom2もゲームエンジンなので実行時にはゲームデータを指定しなければなりません。ビルド時に勝手に生成されるprboom.wadというファイルと、ゲームデータが入ったIWADファイル（オリジナルのDOOM、freedoomなど）の2つが必要です。prboom.wadはカレントディレクトリに置けば勝手に見つけます。IWADファイルはオプション-iwadで指定しましょう。

prboom2起動画面（IWAD: DOOM 1.8）

音声なしで起動したければ-nosound、フルスクリーンではなくウインドウモードが良ければ-nofullscreenというオプションが使えます。フルスクリーンとウインドウモードの切り替えはゲーム内のオプションから設定することもできます。

確認だけで終わってしまいました。次回から組み込み環境への移植を始めたいと思います。

何もない組み込み環境でDOOMを動かす - その2 - 組み込み環境への移植方針

DOOMのクローン実装prboom2を組み込み環境に移植する話です。前回はLinux上で動作確認しました。今回は想定する組み込み環境と移植作戦＆移植です。

組み込み環境への移植作戦

想定する組み込み環境は下記のとおりです。

• CPU、メモリ
• I/O: UARTのみ
• 画面出力: なし
• ファイル: なし
• サウンド: なし
• ジョイスティック入力: なし

改造元にするコードは何でも良いですけど、私は動作するコードから出発した方がやりやすいので、前回Linux上で動作を確認した実装（src/SDL/*）をベースに改造します。移植にあたって障害となりそうなものは、

• SDL
• サウンド機能
• ジョイスティック入力
• ファイルアクセス機能
• 画面描画機能

この辺の機能が移植先の組み込み環境に存在しないことです。順番に対処しましょう。

SDL、サウンド機能、ジョイスティック入力への対処

SDL（Simple DirectMedia Layer、公式サイトへのリンク、リポジトリへのリンク）はC/C++から簡単にグラフィクスや音声、各種入力機能が利用できる、素敵なライブラリです。が、しかし移植先の環境にSDLなどという高等なものはないのでSDLを使用している箇所は削除します。

メイン（src/SDL/i_main.c）、サウンド（src/SDL/i_sound.c）、画面（src/SDL/i_video.c）とジョイスティック入力（src/SDL/i_joy.c）はSDL.hをインクルードか、SDLの構造体やマクロを使用していてコンパイルエラーになるので、エラーになる箇所を全て削除します。

サウンド（src/SDL/i_sound.c）、とジョイスティック入力（src/SDL/i_joy.c）は動作しなくても問題を起こさないように、常に成功もしくは無意味な値を返すように改造します。

ファイルアクセス機能への対処

ゲームエンジンを動作させるにはprboom2ビルド時に生成されるprboom.wadとIWADファイル（オリジナルのDOOMのWADを指してこのように呼ぶそうです）の2つのファイルが必要です。が、移植先の環境にファイルなどという高尚なものはないので、下記の作戦でファイルアクセスなしでも動作するように改造します。

• ファイルデータ: 静的配列に置き換え（変換ツールも作る）
• ファイルデスクリプタ: 独自の構造体に置き換え
• ファイルオープン: prboom.wadとIWADファイル以外は無視（＝常にオープン処理を失敗させる）
• ファイル読み出し: 静的配列からのコピーに置き換える
• ファイルシーク: 静的配列のポインタ移動に置き換える

ファイルアクセスを行うコードはシステム（src/SDL/i_system.c）に実装されていますので、ファイルアクセスしている実装を全部静的配列へのアクセスに書き換えます。他の場所（src/d_main.c, src/w_wad.c）のファイルアクセスしている箇所も同様に置き換えます。

ファイルから配列へ変換

ファイルアクセス機能を置き換えたので、ファイル（DOOM.WADとprboom.wad）をC言語の静的配列に変換する方法も作りましょう。

変換方法は色々あると思いますが、昔作った「CmakeでバイナリをC言語の配列に変換する」やつを使います（2023年6月16日の日記参照）。こやつは適当に作った割に意外と便利です。

画面描画への対処

画面描画を削除するとDOOMが動いているかどうかわかりません。移植先の環境に画面を描画するような高尚な機能はないので、UARTとANSIエスケープシーケンスを利用して画面描画の代わりとします。

UARTの出力を受け取る端末には文字を出力する以外にもたくさんの機能があります。端末の各種機能のなかから「背景色の設定＋空白の出力」をピクセル描画の代わりとして利用します。端末によって対応する機能は異なり（ECMA-48やANSI X3.64仕様が有名）ますが、今回の実装ではANSI X3.64のカーソル移動、文字色の変更機能を使用します。大抵の端末ソフトが実装しているはずです。たぶん。

端末の文字は縦長（縦:横＝2:1くらい、フォント依存です）が多いため、Space 2文字でだいたい正方形になります。つまり背景色変更 + Spece 2文字 = 1ピクセルとすれば画面の描画ができるという寸法です。普通の文字サイズだと1ピクセルが大きくなりすぎるので、端末側のフォントサイズ設定で調整しましょう。

背景色を変更するエスケープシーケンスはこんな感じ。

• 256-color mode: ESC[48;5;<n>m
• 24bit color mode: ESC[48;2;<r>;<g>;<b>m

24bit色モードであれば1つのピクセルを表現するために、エスケープシーケンス16バイト＋スペース2バイト = 18バイト必要になります。極めて効率が悪いですが、とりあえず動かすために先に進みましょう。

方針が決まったところで画面描画の実装（src/SDL/i_video.c）を改造します。prboom2の画面はフルカラーではなくパレット描画なので、パレット操作をする部分も合わせて改造します。

prboom2が動作している様子（ウインドウはPuTTY、画面サイズ128x120、フォントサイズ5pt）

実際描画してみるとこんな感じです。ウインドウタイトルを見るとわかりますが、SDLによる描画ではなくPuTTYという端末ソフトウェアの画面です。

とりあえず動きました。やったね。画面描画が遅い問題は、次回以降対処していこうと思います。

何もない組み込み環境でDOOMを動かす - その3 - 描画の高速化

DOOMのクローン実装prboom2を組み込み環境に移植する話です。前回はUARTしかないショボい組み込み環境でも動作できるようにprboom2を改造しました。

UARTによる画面描画の問題点

Linuxの仮想端末は超速いので描画速度はあまり気になりませんが、組み込み機器に移植すると描画がめちゃくちゃ遅いことに気づくと思います。理由は簡単でUARTが遅いからです。UARTは9600bps〜115.2kbpsがよく使われる速度で、速いものでもせいぜい1.5Mbps程度です。

前回の実装では24bit色モードを使ったので、1つのピクセルを表現するために、エスケープシーケンス16バイト＋スペース2バイト = 18バイト必要です。128x120の画面を1枚表示するのに276kB必要、9600bpsだと230秒（0.0043fps）、1.5Mbpsでも1.47秒（0.67fps）です。

256色モードで軽量化

端末の背景色設定は24bit色モードと256色モードがあります。256色モードの場合、エスケープシーケンス10バイト＋スペース2バイト = 12バイトなので、24bit色より多少は軽量です。128x120の画面を1枚表示するのに184kB必要です。1.5Mbpsで0.98秒（1.01fps）ですね。

256色モードのパレットと色の番号

24bit色モードはエスケープシーケンスでR, G, Bの各値を指定できるのでどんな色でも指定できました。256色モードの場合はパレットの各色に番号が振られていて、エスケープシーケンスで番号を指定する仕組みです。カラーパレットは上記の配置で固定されていてパレットにない色は使えません。

DOOMの画面の各ピクセルの色を見て、256色モードパレットの色を指す番号を探す減色処理を追加します。256色モードのカラーパレット番号と色の関係は規則的です（※）から、それほど難しくないでしょう。

prboom2（オープニング画面）、256色モード

256色モードだとこんな感じです。24bit色版と比較するとややディティールが潰れていて黒っぽいですけど、まあまあ良さそうです。

（※）16-231番（216色）はR, G, Bそれぞれ6段階の組み合わせです。パレット番号を表す式は、16 + 36r + 6g + b (0 <= r, g, b <= 5) となっています。

横方向RLE

もう少し軽くできないか考えてみましょう。今は毎回「背景色変更のエスケープシーケンス + スペース2つ」を出力していますが、左隣のピクセルと色が同じピクセルであれば、背景色変更をする必要はないです。

つまり左隣と同じ色のピクセルが連続する限りエスケープシーケンスの出力を省略できます。非常に単純なRLE（Run-Length Encoding）の一種とも言えましょう。

グレースケールの活用

デモ開始直後のところがわかりやすいですが、256色モードで描画すると真っ黒になってしまう画面が散見されます。

prboom2、24bit色モード

prboom2、256色モード

DOOMの画面は比較的暗い色が多いですが、256色モードのパレットは暗い色から明るい色まで均等に割り振られているため、暗い色の表現力が低いです。単純に近似すると画面の色がほぼ真っ黒になります。

この問題を回避するために暗い色をグレースケールに置き換えます。グレースケールと暗い赤、緑、青は違う色ですが、暗い色の色味は区別しづらいのでグレースケールに置き換えてもさほど不自然にはなりません。

prboom2、256色モード + グレースケール

こんな感じです。良く見ると壁の暗い緑がグレーになっていたり若干変ですが、総じて悪くない仕上がりです。これで256色モードが活用でき、24bit色モードに比べて描画速度が1.5倍以上になりました。

今まではずっとLinuxの上で作業してきましたが、次回でようやく組み込み機器に移植します。