三次元のレトロなシューティングゲームのエンジンをゼロから作成します

私はいつも、クラシックな90年代の一人称シューティングゲームが好きでした。 386番目の Doomで何時間も座って過ごしましたが、320x200の優れた解像度で3Dグラフィックスをリアルタイムで画面上にレンダリングするコードを誰かがどうやって書いたかにショックを受けました。 私は少しプログラミングを知っていました（私はBASICを習い始めたばかりです）ので、それはビデオメモリーに書き込まれた数学とバイトの束にすぎないことに気付きました。 でも当時は、配列でさえかなり複雑な概念だったので、3Dレンダリングの複雑さを理解することさえできませんでした。

当時、他の方法がなかったため、誰もが最初から3Dエンジンを作成しました。 しかし、今日では、3Dレンダリングロジックをゼロから作成することは悪い考えです。 とても悪い。 車輪の発明のように！ 膨大な数の3Dエンジンとライブラリは、自分でできることよりもテストと最適化がはるかに優れているため、合理的な開発者が独自のエンジンの作成を開始する理由はありません。

場合にのみ...

タイムマシンで90年代に戻れると想像してください。OpenGLとDirectXがなく、ビデオプロセッサがありませんでした。 持っているのは、CPUとピクセルでいっぱいの画面だけです。 すべてを自分で書く必要があります。

この考えがあなたにとって興味深いと思えるなら、あなたは一人ではありません：これはまさにTIC-80のような架空のコンソールでできることです。

このコンソール用の私の最初のゲームである8ビットのパンダを書いた後（ 前の記事で読むことができます）、新しいゲームのアイデアを探し始めました。 そのため、単純な3Dエンジンをゼロから記述し、その中に最小限の一人称シューティングゲームを作成するタスクを自分で設定することにしました。

それが私がFPS80を書き始めた方法です。

この記事では、FPS80での3Dレンダリングプロセスについて説明し、この弱いマシンで高速3Dレンダリングを実装する際の速度（および無限の恐ろしいハック！）を確保するためのすべてのトレードオフについて少し説明します。

3Dの基本

3Dレンダリングがどのように機能するかを既に知っている場合、このセクションは退屈に思えます。 すぐに次のセクションに進むことができます！

この記事では3Dグラフィックスの完全な説明は長すぎるため、目的に重要なものを簡単に確認します。

3Dグラフィックスの基本的な考え方は、3D空間を2Dサーフェス（コンピューター画面）に投影することです。 言い換えると、3Dエンジンの主なタスクの1つは、指定された座標（x、y、z）に対して、画面上のポイントがある場所の2D座標空間（x、y）内のポイントを見つけることです。


このため、3Dエンジンは一連の変換を実行します。 変換は、「ある座標系から別の座標系への変換」という表現の簡単な定義です。 変換は、モーション（動き、回転、スケール）と投影を表すことができます。 通常、それらは行列で表されます。

ポイントのスクリーン位置を計算するには、まずモデルマトリックスMに従ってそれを変換し、世界の空間に変換する必要があります。 次に、カメラの位置を考慮するためにVの行列を乗算し、カメラの位置（または目）に変換します。 次に、射影行列Pを適用します。これは、近くのオブジェクトを大きく、遠くのオブジェクトを小さくする透視変換を実行します。 その後、視点を分割して、ポイントを画面（ビューポート）の座標に変換します：

p '= P * V * M * p

この一連の操作をポイントに適用することは、多くの場合、ポイントの「投影」と呼ばれます。 しかし、シーンはドットではなくオブジェクトで構成されているため、3Dエンジンはそれ以上のことを行います。

3Dオブジェクトはポリゴンで構成されます。 それらを描画するために、エンジンは通常、ポリゴンを三角形に分割し、上記の式を使用して各三角形の各頂点を投影し、画面上の画面スペースの結果の三角形を描画します。 このプロセスはラスター化と呼ばれます。ベクターシェイプ（三角形）からラスターシェイプ（画面ピクセル自体）への変換です。 しかし、三角形をランダムな順序で描くと、良い結果が得られません。 遠い三角形が中央に描かれていることが判明する可能性があるため、エンジンはこのような問題を解決するための戦略を使用する必要があります。 通常は、ポリゴンを事前に並べ替えるか、各ピクセルの深度が表示用に書き込まれる深度バッファーを作成することで解決されます。これにより、いつ、いつピクセルを描画するかを知ることができます。

テクスチャマッピングとライティングを追加します。これは、ピクセルの最終的な色を計算するためにエンジンが計算するもう1つの数学レイヤーです。

完全な3Dが必要ですか？

正直なところ、私は上記の完全な3Dグラフィックス作成プロセスを実装し始めましたが、TIC-80では遅すぎることに気付きました。 古いPCと同様に、すべての数学的な計算とレンダリングはCPUを簡単に過負荷にしてゲームを遅くする可能性があります。 テクスチャを重ね合わせた回転キューブを4つだけ描画する例を作成しましたが、これでもフレームレートを10 fps未満にするには十分でした。 「フル3D」が機能しないことが明らかになりました。 特に、 充填率は「ボトルネック」になりました。つまり、問題は主に投影点の数学にありませんでしたが、三角形のすべてのピクセルを画面に描画するのにかかる時間、特にポリゴンが画面の重複部分を占有します。

しかし、完全な3Dが必要ですか？ 実際、90年代の多くの古いゲームは「フル3D」を実現していません。 代わりに、グラフィックスを制限するトリッキーなメカニズムを実装して、コストを削減します。

それで、ここに私が導入した制限があります：

• 全体のレベルはフラットです。階段、ピット、バルコニー、2階などはありません。 つまり、床と天井の高さは一定です。
• すべての壁は、床から天井まで同じ高さです。 そして、それらはすべて不透明です。
• プレイヤーはどの方向にも向きを変えることができますが、頭を上下左右に傾けることはできません。 言い換えると、カメラの回転の自由度は1つだけです： courseまたはyaw 。
• すべてのオブジェクトは「ビルボード」として描画されます。つまり、2D画像は常にカメラに向けられるように3D空間に描画されます。
• 点光源のみがあります。 それらの1つは常にカメラ内にあります（プレーヤーの手にあるトーチのように）。 他のものは、たとえば爆発の影響のために、短時間で作成できます。

これらの制限はどのように役立ちますか？

床と天井が一定の高さを持ち、すべての壁が床から天井へと移動する（そしてプレイヤーが上下に見ることができない）という事実は、私たちにとって非常に役立つ素晴らしい特性を生み出します：Xスクリーンの各位置には1つの壁しかありません。 つまり、表示されるすべての壁が画面の中央を占め、2つの異なる壁が同じX座標を占めることはありません。


壁をより見やすくするために、さまざまな色でハイライトします。


ご覧のとおり、スクリーンショットには6つの壁があり（ドアは「壁」でもあります）、それらはすべて画面上に非常に便利に配置されています。画面の各X座標は1つの壁のみに対応します。

これは、壁を2段階でレンダリングできるため、非常に便利です。

• 各X座標に表示する壁を決定します（言い換えると、X座標から壁へのマップを作成します）。
• （一度だけ！）すべてのX座標を回って、壁の必要な部分ごとに描画します。

エンティティ（オブジェクト）-モンスター、貝、柱、噴水、木など-には、よく使用されるビルボード技術を使用します。 エンティティは実際の3Dオブジェクトでは表現されません。段ボールから切り取った図形として、3D座標で平らな2D画像を描画するだけです。 このメソッドは、レンダリング時に非常に安価です。

投影手順

非常に単純化された3Dの世界でさえ、3D空間から2Dにポイントを投影する必要があります。 ただし、私たちの制限により、数学的計算ははるかに簡単かつ高速に処理されます。 完全な行列乗算を行う代わりに、はるかに簡単な方法でそれを行うことができます：行列計算の不変部分（プレーヤーまたはオブジェクトの位置に依存しない部分）を定義し、単純に以前に計算された値をコードに挿入します。 このすべてについて簡単に説明しますが、詳細な計算に興味がある場合は、次のように表示されます 。

式を覚えておいてください：

p '= P * V * M * p

ここで、p 'は画面座標（出力）であり、pは世界座標（入力）です。 単純なモデルでは、Mは恒等行列（すべてがワールド空間で表されます）、つまり、次のようになります。

p '= P * V * p

可視性マトリックスVは、カメラを移動および回転するだけで計算できますが、カメラはY軸に沿った回転のみによって制限されます。

p '= P * R * T * p

射影行列Pは、ゲーム全体を通して一定であるスコープとニア/ファークリッピングプレーンのみに依存するため、事前に計算できます。 計算を単純化した結果、結果として、かなり単純な（コードで設定するのがすべて難しい場合）投影関数になります。

function S3Proj(x,y,z) local c,s,a,b=S3.cosMy,S3.sinMy,S3.termA,S3.termB local px=0.9815*c*x+0.9815*s*z+0.9815*a local py=1.7321*y-1.7321*S3.ey local pz=s*xz*cb-0.2 local pw=x*sz*cb local ndcx,ndcy=px/abs(pw),py/abs(pw) return 120+ndcx*120,68-ndcy*68,pz end 

次のマジックナンバーを見てください：0.9815、1.7321など。 それらはすべて、事前に準備されたマトリックス計算から取得されます。 それ自体では、直感的な値はありません（したがって、定数に変換することさえしませんでした）。

変数cosMy 、 sinMy 、 termAおよびtermBは、関数を呼び出す前にカメラの現在の動きと回転から計算されます。すべてのポイントに対して一度だけ計算すれば十分だからです。

壁のレンダリング

最初の段階では、 H-Buf（水平バッファー）と呼ばれる配列を使用します。これは、画面の各X座標に何が描画されるかを決定します。 「H-Buf」は非標準の呼称であり、私自身が発明しました。 H（水平）およびBuf（バッファー）であるため、H-Bufと呼ばれます。 名前を発明するとき、私はあまり独創的ではありません。

TIC-80画面には240列（240x136）が含まれているため、H-Bufには240の位置があります。 各位置は画面のX座標に対応し、そこに壁のどの部分を描画するかに関する情報が含まれています。 物事を単純化するために、私はそれを「1ピクセル幅の壁」ではなく「壁カット」と呼びます。 つまり、H-Bufの各位置は、画面の各X座標で描画する壁のセクションに関する情報を提供します。

• 壁（オブジェクト）： -これは、このスライスに描画される壁へのリンクです。
• z（浮動）： -このスライスの画面空間（深さ）のz座標。
• などなど...しかし、今のところはそれについて話しましょう！

少なくとも最初の段階では、これで十分です。 そのため、レベルのすべての壁を移動する必要があります（すぐに、この操作をより効果的にする方法について説明します）。 各壁について：

• 投影関数を四隅で使用して、画面上のどこに表示されるかを決定します：左x、右x、左上y、左下y、右上y、右下y、左z（深さ）、右z（深さ）。
• 壁の各X座標（left_xからright_xまで）を巡回し、 その深さが H-Bufのこの位置にある既存のセクションよりも小さい場合、壁のセクションをH-Bufに書き込みます。

最初のテスト「このスライスの深さは既存のスライスの深さよりも小さい」は、 深さテストと呼ばれます。 これにより、壁を正しい順序でレンダリングできます。プレーヤーに最も近い壁が遠い壁と重なります。 関連するコードスニペットを次に示します。

 function _AddWallToHbuf(hbuf,w) local startx=max(S3.VP_L,S3Round(w.slx)) local endx=min(S3.VP_R,S3Round(w.srx)) local step local nclip,fclip=S3.NCLIP,S3.FCLIP startx,endx,step=_S3AdjHbufIter(startx,endx) if not startx then return end for x=startx,endx,step do --  hbuf   1 (   Lua) local hbx=hbuf[x+1] local z=_S3Interp(w.slx,w.slz,w.srx,w.srz,x) if z>nclip and z<fclip then if hbx.z>z then --  . hbx.z,hbx.wall=z,w --       end end end 

各壁に対してこの操作を実行すると、H-Bufには各X座標でレンダリングするスライスに関する正しい情報が含まれます。つまり、レンダリングするために必要な壁の正しい部分を周期的にレンダリングするだけです。 これにより、このアプローチは迅速であることがわかりました。壁を描くとき、​​遅延や余分な作業はありません。ここで描画し、タッチする必要があるピクセルのみをタッチする必要があることは確かです。 私たちの国では、最初に壁の一部を描いて、その上に別の壁を描くことはありません（再描画なし）。

これがレンダリングコードです。 それがいかに単純かに注意してください：各Xに対して、そのX座標でテクスチャ列をレンダリングするだけで、それ以上は何もしません：

 function _S3RendHbuf(hbuf) local startx,endx,step=_S3AdjHbufIter(S3.VP_L,S3.VP_R) if not startx then return end for x=startx,endx,step do local hb=hbuf[x+1] --  hbuf   1 local w=hb.wall if w then local z=_S3Interp(w.slx,w.slz,w.srx,w.srz,x) local u=_S3PerspTexU(w,x) _S3RendTexCol(w.tid,x,hb.ty,hb.by,u,z,nil,nil, nil,nil,nil,w.cmt) end end end 

非常に奇妙なトリックでフレームレートを2倍にする

TIC-80の解像度は240x136しかありませんが、時間をまったく無駄にせず、描画する内容を正確に把握していても、画面全体を表示するとCPU電力のかなりの部分を消費します。 単純なシーンでは最速のレンダリングアルゴリズムでも約30 fpsを生成しますが、より複雑なシーンでは周波数が大幅に低下します。

この問題をどのように回避しますか？

自問する必要があります。画面全体を埋める必要があるのでしょうか。 いいえ、必要ありません。 人間の目は、動きの速いイベントの欠点を「滑らかにし」ます（レトロゲームをプレイする人は小さな視覚的な「グリッチ」に非常に寛大です！）。したがって、各フレームの画面の半分だけを埋めることでレンダリングを高速化できます。

次のことを行います。

• 偶数フレームでは、Xの偶数座標のみを描画します。
• 奇数フレームでは、Xの奇数座標のみを描画します。

このプロセスは、 インターレースレンダリングとも呼ばれます 。 つまり、各フレームでは、240x136全体ではなく、120x136ピクセルのみが実際にレンダリングされます。 各フレームで画面をクリアしないため、描画しないピクセルは前のフレームの残りとして単純に保存されます。

これは、特に速い動きで、小さな目に見える「グリッチ」を引き起こしますが、実際には、それはテレビ画面にレトロな感じを与え、それに対してではなく、ゲームに対して機能します。

以下は、実際に各フレームをレンダリングするものです（少なくとも、他の列が前のフレームのピクセルでまだ満たされていなければ表示されます）。


1フレームのインターレースレンダリング。 わかりやすくするため、レンダリングされていない列は空白のままにします。 実際、前のフレームのレンダリング結果で埋められます。

ウォールスライスレンダリング

さて、ここで壁のスライスのレンダリングに移ります。 どのスライスをレンダリングするかはすでにわかっており、どこにあるかはわかっています。 実行する必要があるのは、この列にレンダリングするピクセルとピクセルの色を決定することだけです。 どうやってやるの？


壁スライス（1ピクセルの厚さの壁の垂直ピクセル列）。

• 光源と距離を考慮して、このスライスへの照明の入射を計算します。
• テクスチャの水平座標を計算して、壁を切り取ります（遠近補正を使用）。
• 壁の終点を補間して、スライスの上下のY座標を計算します。
• 各ピクセルを上から下に塗りつぶします。つまり、テクスチャの垂直座標を決定し（アフィン変換）、テクスチャをサンプリングし、次に照明を変調し、最後にピクセルを画面に書き込みます。

画面に対する壁が常に垂直に立っているため、テクスチャの垂直座標のアフィン変換を行うことができます（視点の観点から正しい変換の代わりに）（これは、プレイヤーが頭を上下左右に動かすことができないため保証されます）。 状況が異なる場合、水平と垂直の両方のテクスチャ座標に対して正しいテクスチャマッピングを実装する必要がありますが、これは遅くなります。

エンティティのレンダリング（ステンシルバッファーを追加！）

さて、壁は楽しいですが、エンジンは敵のいないゲームにはなりません。 前述したように、敵はビルボードのようにレンダリングされます。つまり、フローティング画像として、常にプレイヤーに向けられます。


ビルボードとして描かれたエンティティ（常にカメラに向けられます）。

ただし、これらの画像は単なる2次元ではありません。空間の特定のポイントで描画されるため、 depthがあります。 敵が壁を越えた場合、壁は敵の前にレンダリングされなければならず（敵は壁によってブロックされなければなりません）、それ以外は何もしません。

この効果を達成する方法は？

物事を単純化する場合は、アーティストのアルゴリズムを使用できます（これは、アルゴリズムの欠如に似ています）。オブジェクトを後ろから前に描くだけで、前景のオブジェクトは自然に背景のオブジェクトの上に描かれ、目的の効果が得られます。

彼の何が悪いの？ わかりやすい。 書きやすい。 しかし...特に充填速度が制限されているTIC-80では非常に遅いです。 このような実装では、後で他のピクセルで簡単に覆われるように、美しくテクスチャ化され、照らされたピクセルのレンダリングに多くのリソースを費やします。

そして、ここで、新しいバッファ、ステンシルバッファを導入する必要があります。 3Dレンダリングでは、ステンシルバッファーは、描画可能な場所と描画できない場所を示す2D画面サイズのサーフェスです。 フィルターのように見えます。 ステンシルバッファの各ピクセルは、「オン」、つまり「ロックされ、描画しない」または「オフ」、つまり「自由に描画できます」にすることができます。 実装によっては、値が逆になる場合がありますが、コードでは「true」という値を使用して、「ビジー、描画しない」状態を示します。

プログラムがステンシルバッファを読み取る場合、描画する前に、ステンシルバッファがすべての位置でオンになっているかどうかをチェックします。 その場合、既存のピクセルの上にピクセルをレンダリングしません。

プログラムが「ステンシルバッファに書き込む」とき、これは、画面上の特定の位置に何かをレンダリングするときに、ステンシルバッファに書き込み、この位置がすでに取得されており、再描画すべきではないことを示します。

だから、ここで私たちがやることです。 壁をレンダリングする前に 、H-Bufを計算した後 、エンティティを描画します。 完全なアルゴリズムは次のとおりです。

1. ステンシルバッファをクリーニングします。
2. H-Bufを計算します。
3. エンティティを前面から背面にレンダリングします（読み取り/書き込みステンシル、H-Bufの深度テスト）。
4. H-Buf（読み取りステンシル）を使用して壁をレンダリングします。

各エンティティの各ピクセルをレンダリングするとき、ステンシルバッファーに書き込み、その上にレンダリングされる他のすべてを禁止します。 そのため、前から後ろへ順番にレンダリングする必要があります。 これは、 描画するすべてが最終的なものであることを意味します 。 これは再描画を行わないことを意味し、画面に描画されたピクセルを無駄にすることはありません。

エンティティをレンダリングするとき、画面スペースの深さを知り、このX位置の壁の深さを知っています（H-Bufのおかげです！）。したがって、この列の深さもテストできます。 これは、（レンダリングのこの段階では壁がなくても！）壁の後ろに隠されるエンティティの部分をレンダリングすることを正しく拒否することを意味します。 ここでも、1つの余分なピクセルを費やす必要はありません。 彼らは私たちにとって非常に高価です。

次に、4つのビルボードが重なっているシーンと、レンダリングされる順序の例を示します。 最初に噴水（番号1、最も近い）、次に木（2）、次に緑のモンスター（3）、オレンジのモンスター（4、最も遠い）が来ます。

床と天井はどうですか？

床と天井は、エンティティと壁をレンダリングした後に残る唯一のピクセルであるため、プロセスの最後の段階でレンダリングされます。 天井はすべてシンプルです。完全に黒で、これらのピクセルを塗りつぶし、H-Bufを見て、壁の始まりを決定します。 その上の各ピクセルは黒です（ただし、ステンシルバッファーはチェックされます）。 できた

照明効果を適用する必要があるため、床はより複雑になります。床からプレーヤーから遠い部分をより暗くする必要があります。

しかし、照明を計算するには、床の各ピクセルの深さを知る必要があります。 ピクセルごとに定義するのは驚くほど簡単です。なぜなら、世界空間の座標を決定するために画面空間の座標から逆の順序で開始し、プレーヤーからそれらまでの距離を決定するからです。 さらに、手順が非常に簡単になるように、すべてを手動で事前計算し、これらのマジックナンバーを入力できます。

 function _S3FlatFact(x,y) local z=3000/(y-68) return _S3LightF(x,z) end 

床上のピクセルの指定されたx、y座標の場合、床上の対応するZ座標は3000 /（y-68）のみです。 理由はわかりませんが、それは紙のコンピューティングから起こったのです。 そして、 _S3LightFでこれを使用して、床の色の調整に対応する、このポイントに当たる照明の量を計算します。

これが、フロア照明パレットの外観です。 プレーヤーから離れると徐々に暗くなることに注意してください。

追加の点光源

たとえば、プレイヤーが火の玉を投げて爆発した場合など、照明効果のための一時的な点光源のサポートを提供します。


原理は同じです：描画される点から二次光源（爆発）までの画面空間の距離を計算し、その効果を考慮します。

このエフェクトは、コストがかかり、信頼性が高くないため、連続照明（壁のトーチなど）には使用しないことに注意してください。 画面スペースで計算されるため、カメラの回転と動きは実際には考慮されず、ソースがプレーヤーに近すぎると不快な機能とゼロによる除算が行われます。

カラー変調とディザリング

TIC-80は16色のみで動作しますが、ピクセルを明るくしたり暗くしたりして照明効果を作成するにはどうすればよいですか？

私は次の手法を使用しました。暗いから明るいまで、4つの異なる色合いを持つ3つの異なる「トーン」を作成しました。 これらのトーンは、それぞれの4つの濃淡の1つを選択することで変調でき、さらに最も暗い色として黒（色0）を選択できます。 その結果、グレー、グリーン、ブラウンの3つの「線形変化」が得られます。

 clrM={ --  "" {1,2,3,15}, --  "" {7,6,5,4}, --  "" {8,9,10,11} }, 

それらは単純な配列として定義されているため、一定量の照明の色を調整する必要がある場合は、色を見つけて、同じ線形変化の他の色を選択する必要があります。

中間色はどうですか？

彼らのために、古いグラフィック機器で使用されていた戦略、 ディザリングを適用しました。 中間色の1つのピクセルを使用することはできないため、ピクセルの一部に1つの色を使用し、他の部分に異なる色を使用するパターンを描画します。 その結果、目はそれらを中間色として認識します。

パーティクルエフェクト

モンスターを殺したりオブジェクトを破壊したりするときにプレイヤーに素晴らしいフィードバックを与えるために、単純なパーティクルエフェクトを使用します。


これらは、ワールド空間でシミュレートされ、レンダリング段階で画面空間に変換される小さな長方形です。 速度上の理由から、これらは切り取られず、ステンシルバッファでは考慮されず、他のすべての上に単純に描画されます（「余分なピクセルを無駄にしない」という原則からのわずかな逸脱）。 幸いなことに、インターレースレンダリングは、長方形であるという事実を隠しています。これらは高速で移動し、各フレームを異なる位置にレンダリングするため、パーツにインターレースされ、より「オーガニック」に見えます。

おわりに

この記事では、FPS80のレンダリングプロセスについて簡単に説明しました。 私は3Dエンジンをゼロから作成した経験がなかったので、多くのことを改善できると確信しており、私の説明は大部分が間違っています。 エラーを見つけたら私に連絡してください（ Twitterで私に書くことができます）。

独自の3Dレンダリングロジックの開発は、非常に興味深く有益なものであることがわかりました。 特に面白いのは、アルゴリズムの速度を落とす必要があることです。 これにより、90年代に3Dエンジンがどのように作成されたかについて（小さな）アイデアが得られました！

FPS80ソースコードとレンダリングエンジンはgithubで入手できます。 プロジェクトで自由に使用してください！

---

ご注意 プレイ方法： TIC-80 仮想コンソールをコンピューターにインストールします 。 TIC-80を起動し、 surf コマンドを入力し ます。 [tic.computer/play] を選択し、Zを押して選択します。 リストで FPS80 を FPS80 、 Zを押して開始します。 TIC-80 Webサイトで ゲーム を プレイすることもでき ます （ただし、そこで音が途切れます）。