Firefox3

リリースおめでとうございます。position:fixedで配置されてるレイヤーがあると激烈に描画が遅くなるのは結局直らなかったんだなあ。keyconfigとTab Mix Plusが普通には入れられない状態なのもまずい気がする。いや。いいんだよね。デフォルト状態でおすすめ<アドオン>ベスト10とか入れれば十分なのだよね。キーボードショートカットとマウスジェスチャばっかり使ってせっかくでかくなったBackのボタンなんか使わないとか、そもそも戻る進む以外のツールバーボタンは全部削除しちゃって、メニューバーの項目も削ってるとか、余ったスペースにliveclick化したライブブックマークを大量に並べてるとか、Adblock、Noscriptなんていれねーよとか、https://addons.mozilla.org/ja/firefox/addon/5846(よろしくね)を入れてるとか、そんなユーザーはいないんだよ。よかった。

ポイントライトと加算混色

以前エントリにしたピクセルシェーダでsrccolorに基づいてalphaをいじってdestcolor*(1.0-srcalpha) + srccolorすることで適当に背景を暗くしつつ加算混色する方式を今回の嘘ポイントライトの混色にも使ってみた。当然のことながら光の混色は加算混色なのでバカ正直に計算すると複数のライトが重なるとすぐに色成分は飽和して真っ白になる。これは前の加算合成のエフェクトと同じ。向こうはまだそれが迫力といいはることもできなくもないが、こちらはちょっと光源の影響範囲が重なっただけで白くなりすぎて明らかに変だった。改変により満足のいく結果が得られた。

バグ 傾向と対策

  • 先述のメモリリークの件で修正した周辺、配列にコールバックを登録するところで以前は全部にデフォルトの空関数を最初に登録していたが修正時に取り払ってしまっていてaccess violation。
  • エンティティ個別のデータベース内で自分の装備アイテムへのポインタをキャッシュするように変えたが、通信経由でのアイテム情報更新時にキャッシュの方の更新をし忘れておりaccess violation。
  • エンティティからみたらpersistencyをもたないキャラクタの体描画区分にエンティティ初期化時にだけ色を調整するための変数へのポインタを送りつけてそれでよしとしてたら、ネット駆動のエンティティで実際に体描画区分が動的に入れ替わってしまい色変更が影響しなくなった。

わずかなパフォーマンス向上を求めてへんなことしてるところで問題がおきがち。うーん。対策はどうすりゃいいんだろうね。

  • アイテムをどこに装備してるかをenumにしていてなおかつ装備品ポインタ配列のインデックスにも利用してたが、処理上ヌル的な値を使わざるを得ない場所がありenumにも設けたが配列の範囲外の値にしておりaccess violation

RoAバージョン3をリリースしました

これが本来の意味での作業記録だな。一応公開しました。本来あるべき迷宮探検での光源問題にスポットをあてた新感覚RPG!というような煽り文句をつけられるかもしれない。立体交差のほとんど無い2.5次元マップだからこそできたpixel shaderを使った数量制限のないダイナミックポイントライト。物理的にはおかしいけど割と違和感がなく臨場感のある自分中心影。そして悶々としてる間に思い至った企画としての方針変更を一部適用。少しずつ個々が力をだしあって、みたいなネトゲはもう流行らない、というかそもそも流行ってないし。だからちょっとオーバー気味につけてた枷をはずす方向へ舵を切りました。

描画でさえももはや構造化できない

極限まで抽象化された概念であるところのゲームオブジェクトはおそらくもともとは画面への描画の最小単位として使われることで意義をもっていたのではなかろうか。要するに昔はオブジェクトがそれぞれ単純に自分自身を自分自身に基づいて描画するだけで画面が描画でき、単純明快な一部品として扱えていた。しかし、例えば最近のシャドウマッピングなどのマルチパスレンダリングが主流になってくると、自分自身を描画するときに自身や他のオブジェクトがすでに描かれたテクスチャがあることを前提としなくてはならない場合もある。描画するだけでも他のオブジェクトの描画結果に依存する必要がでてきてしまった。また、テクスチャを参照する必要がなかったり、透明度を無視してもよかったり、描画する内容も複数の描画指示のあいだで全く異なる。スーパークラスのポインタを渡してのんきに描画命令がとどくのを待つだけというわけにはいかない。描画処理の全体の流れの中のどこでなにを描画するか言及する必要がでてきてしまった。

描画処理の側面からみてももはやゲームオブジェクトはすべてが全く同じものだとはみなせない。

どうするか。ふたつまえのエントリのようにヒントを用いることで厳密性はないもののこれまでのオブジェクトリストを維持するか。ひとつ前のエントリを受け容れて走査部がそれぞれのオブジェクトへ完全依存する手もあるだろう。結局のところ、いまや新しい種類の描画対象が加わえられた場合、いつどこでどのような内容を描かせるかまで定める必要があるのだから完全依存の方へ行くべきだろう。だが将来3DCG描画のパラダイムがごっそり変わってもとにもどってくる可能性もある。

ゲームオブジェクトの最適な一般化の程度は

酔っ払いながら書いた自分のためのメモがホットエントリに一瞬顔出しただけでアクセス数が一桁違って戸惑ってしまった。いきなりわけのわからん文章を読まされた方も戸惑っていることだろうと思う。でもそんなの関係ねえ!

自分たちが作っているのはあくまでゲームルールを駆動するアプリケーションなのであって、ゲーム内の概念をクラスヒエラルキーへ写し取ることではない。短絡的にこれが可能だからといって、ゲームオブジェクトをみて「これがオブジェクト指向か〜」と言ってクラスヒエラルキーでゲーム世界を表現するのは愚の骨頂。あとでゲームオブジェクト間の依存をどうするかでグローバル変数やダウンキャストや独自IDという地獄にはまることになる。

自分の主張の根拠はゲームルールがどういうものかという点にあるので、最適な一般化はゲームルールを記述する範囲内でアイデンティファイできる程度ということになる。前のエントリの例がそのままで、これ以上もこれ以下もないということだろう。