本命彼女の帰国繰り上げによりその日が間近に迫っているので、今夜は急遽非本命彼女A:DLLと好きなイタリアンへ。俺はピザとワインが大好きなのだが、気になっていた店が「行ってみないとワカランな」要素のある店だった。しかしここは非本命。自由だ。結果的にかなり美味しかったのでローテーションに組み込んでみよう。うん。

 昨夜のアーティクルへ心温まるコメントを頂いたので、無断引用した上で「最先端ゲームプログラマ」として技術系の話を掘り下げてみたいと思う。

 

 「しん」さん、「ゆーと」さん、コメントをどうもありがとう、ありがとう。
以下、引用です。


>1. しん 2009年11月10日 08:28
>ダメだ。
>前半何言ってるかワカンねェ…(--;
>
>2. ゆーと 2009年11月10日 15:11
>ゲームエンジニアって、ちょっと憧れていますので、大変参考になります。
>
>別分野のエンジニアですが、本命彼女や非彼女はわかりませんがそれ以外はおもしろかったです(笑
>
>
>ゲーム業界では、ベクタテーブルとか使われなくなっているのでしょうか?
>DSとかだとARMなので、FIQとIRQとか使い分けてるのかと思ったのですが。
>
>
>また、私は若手のSEの部類なので間違っているかもしれませんが、「パレット=>パレットレジスタ」とか「バンク=>裏画面切り替え」ですか?
>
>PC98でちまちまといじってた3年半前の懐かしい思い出が・・・。

 

 「往年の技術系ネタにコメント頂けるとノリノリになってしまう人間」、この様に明言した途端なので、はい。ノリノリになってしまった。書くぞー。古い人間が喜びそうなネタを!
恋愛工学はとりあえず次稿だスマン。

 

 ちと殴り書きな稿であったので判りづらく申し訳無い。
技術者の方の為に前回のアーティクルについて少し噛み砕いてみたいと思う。

 
 「ヒープコメント文字列を、デフォルト削除で運用しなければならない」
これは重要だ。良く読んでくれ。
中堅ゲームプログラマが在る一定の実装力を備えた暁には、まず疑問に思うであろう。
「newってなに?使い方は勿論知っているけれど、本当は内部で何してんの?」って事だ。現代ゲームプログラムにおいてはC++は世界標準言語である。その運用において「newキーワード」も又標準であるが、その仕組みについて考える事は良いプラクティクスである。
この「new」は、フリーで使えるメモリ群を要求する魔法の言葉では「ない」。よく考えてくれ。
量子コンピューティングの世界が訪れているのでは無い以上、現代アーキテクチャにおいてメモリというものは、単に一次元の記憶スペースに他ならない。
色々なモジュールが要求するメモリ空間を無利子で貸し付けるサラ金屋の役目を補っているのが「new演算子」だ。この領域はいずれ絶対に返して貰わなければらなない。「new演算子」も必死だ。

 彼等が行っているのは「メモリ配分」なのである。寄与では無い
であれば、これを開発チームで受け持つ事も理論的に可能ではあるし、デバッグ効率を高める為には、「OSに頼っているのでこの部分は知りません」的な要素を無くし理解の範囲を深める事は有効なアプローチだ。

 この様な理由で我々職業ゲームプログラマは、通常「new演算子」をオーバーライドする。newが呼ばれた際に、自身のコードへプログラムがやってくる。メモリ全域を自分達で管理しているのだ。まあ、基礎中の基礎だ。

 ここからが本題なのであるが、我々はこの仕組みに少しイタズラを仕込んでいる
メモリ全域を自分達で管理しているので、融通が利くわけだ。

若きプログラマさん達向けに種明かしをすれば、newを使用した場所全てを各メモリブロックが記憶しているのだ。これによりメモリリークを追い込む手がかりを確保出来る。

 前アーティクルで述べた「ヒープコメント文字列を、デフォルト削除で運用しなければならない」とは、この機構を採用しないビルド設定にて運用せざるをえない程のメモリ削減に努めなければならない様な状況を表しているのだ。

 

前回アーティクルに示した「デバッグ用頂点プリミティブ等で既に埋め尽くさかけている」、これはもっとシンプルだ。
 開発中の例えばプレイヤーが歩けるマップにおいて、コリジョン判定を目視で確認したい場合に、ワイアーフレームにてそれを描画してしまう。但しこれらには大量の頂点情報を独自に伴う。このメモリ空間が必要だという事だ。

 

さて今度は「ゆーと」さんの番だ。
彼の質問が俺をノリノリにさせた。
業界は違う様だが「判っている人」だ。旨い酒が呑めそうだ。


>ゲーム業界では、ベクタテーブルとか使われなくなっているのでしょうか?
>DSとかだとARMなので、FIQとIRQとか使い分けてるのかと思ったのですが。


ベクタテーブルという仕組みは相当に過去の遺物と考えられています。理由は至極シンプル。ゲームプログラムは総じてオブジェクティブであるべきであると考えられているからであります。もう少し具体的に言えば、グローバルなオブジェクトの存在意義が無いからなのです。勿論OSの最深部にはこの様な仕組みが存在しますが、我々最前衛のプログラマは、ファーストパーソンメーカーそれぞれが独善的に決める気まぐれな細かい仕様を意識した設計をする事はありません。合理性の欠如は基より、移植性が死にますからね。
DSの様な原始的なハードにおいては「ゆーと」さん仰るIRQ等の管理をある意味では未だに強いられます。本当にナンセンスな事です。
現代ゲーム業界においてマルチプラットフォームは必然なのですが、とは言え、次世代機とDSで同じクォリティは出せません。我々が重視しているのはクォリティではなく生産性と合理化なのです。例えばコリジョンの判定数学プログラムは、本質的に正しく実装すればPS3でもDSでも同じコードをビルド出来る筈です。そうであるべきです。そういう事を発端に機種間差異の吸収が各社のスキルになりつつあり、我々であれば、そこへDSまでも含めて生産性や合理性を追求しているのです。
(ちなみに、この辺りを気にしていないメーカーの多さは日本が一番です。)
悲しい事ですが、IRQ等の懐古技術はねじ伏せてナンボの要素になっているのが現状なのです。

「パレット」とは仰る通りレジスタ群ですが、ここで記したのは所謂カラーレジスタです。現代シェーダー群への要素として敢て当てはめるならば、ピクセルシェーディング用の、テクスチャカラーをもとめる際のフェッチングキャッシュとでも言った所でありましょうか。過去のハードにおいてはピクセル辺り32ビットダイレクトカラーを当てはめるだけの帯域がありませんでした。よって文字通り絵の具のパレットの様にカラーレジスタ群へのINDEXアクセスは、時代の基本技術でありました。懐かしいですね。

「バンク」とは、文字通りbankingアーキテクチャです。
アドレスレジスタが16bitしか無い様なハードウェアしか存在していませんでしたから(ファミコン、PCエンジン、みんなそうです。メガドラは違いますが)、増加するリソースへの対応が必須でありました。あのアーキテクチャは当時も我々プログラマが提言したのです。
「ページ番号」を指定する事によって、メモリ空間をページ切り替え出来る機構です。アクセス可能空間が16bitしかないので、それ以上の空間へアクセスするための言わば苦肉の策ですね。

呑み会に行ってもハード屋とプログラマは喧嘩ばかりでしたが、バンクアーキテクチャは我々が勝ち取ったものです。事実上無限のメモリ空間を手に入れましたからね。

 

すんごく色々書いていますが、自分の文章読んでちょっと気になった。
なんか、すんげーおっさんじゃね?
一応明言しちゃいますが、俺はまだ30代だw(十分におっさんだとも言える)


ご静聴、thxなのだ。