日記

あたり判定のベースを矩形にすべきか円にすべきかで悩む。一見、矩形ベースのほうが簡単そうだが、実は矩形には、頻繁に書き換えるべきパラメータが4つもあるという欠点がある。円のパラメータはX座標、Y座標、半径の3つだが、半径はそう変化するものではないから、実質的に2つといってよい。

あたり判定処理だけに着目すれば、確かに矩形同士のほうが若干有利（一応、計測してみた）だが、ゲームをトータルで見ると、円ベースのほうが有利かもしれない。

回転砲台、ワインダー銃を作る。どんどん処理が重たくなる。

よくよく考えてみると、やっぱり「円と線分」より「矩形と線分」のほうが楽かも。なにせ、ここでいう矩形は軸に対して平行だから。まあ、どっちみち直線の傾きは計算しないといけないみたいだから、どっちもどっちかもしれないな。

円ベースも捨てがたいなー。でも混在は嫌だなー。

円同士の接触判定をC++で実装した。矩形同士の接触判定処理（TJS実装）と速度を比較したところ、円同士の判定のほうが平均してごくわずかだが速かった。ということは、ゲーム全体としては、接触判定を円ベースにしたほうがいいような気がする。円ベースのほうが、矩形ベースよりも扱いやすいし。

円ベースに変えた。コーディングが楽になって嬉しい。

ダブルバッファをソフトウェアで実装するのをやめた。コーディングが楽になって、メモリ消費量も減って嬉しい。ちょっとスプライトがちらつくけど、いつか小人さんが解決してくれるに違いない。

NORMAL 1コンティニューALLで1200万。ヘタレです。

やはり矩形も捨てがたい。縦長、横長のあたり判定部を表現するには、矩形のほうがいいだろうし。

なぜかゲーム関係の処理ばかり実装している気がする。もともとゲームを作るつもりではなかったのだが。おかしいな。

乱数テーブルクラスを作成。乱数発生器にはMersenne Twisterを使用。予め配列にしておけば、毎回乱数を発生させるよりも速いかも、と思ったが、実測値ではほとんど変わらず。が、このクラスの真の目的はセーブ・ロードメソッドによる乱数の再現にあるから、速度パフォーマンスは正直言ってどうでもいい。

ジョイスティック入力状態をビットフィールドで表現したいのだが、これをC++ネイティブで書いてみる。例によってDLLプラグイン。

static iTJSDispatch2 * TJSSystem;

extern "C" HRESULT _stdcall _export V2Link(iTVPFunctionExporter *exporter)
{
    ...
    // global.System 取得
    tTJSVariant val;
    iTJSDispatch2 * global = TVPGetScriptDispatch();
    if (TJS_FAILED(global->PropGet(0, TJS_W("System"), NULL, &val, global)))
        TVPThrowExceptionMessage(TJS_W("invoking of global.System failed."));
    TJSSystem = val.AsObjectNoAddRef();
    ...

tjs_error TJS_INTF_METHOD FuncCall( ... {
    ...
    for (int i = 0; i < num_keys; i++) {
        *(param[0]) = keys[i];
        TJSSystem->FuncCall(TJS_MEMBERMUSTEXIST, TJS_W("getKeyState"), &_hint, &val, 1, param, TJSSystem);
        intval = val;
        if (intval != 0x0000) {
            intval = 0x0001;
        }
        rv |= (intval << (num_keys - i - 1));
    }
    ...

この調子で直線描画、円描画関数も作ってみようかと。描画が点と矩形だけじゃ寂しいからね。

昨日作ったプラグイン関数のベンチマークテストをしようと思った矢先のこと。この関数、吉里吉里起動直後に呼び出すと、ハードウェア例外が発生する。

21:45:03 EAccessViolation at util_generic.tjs line 251 [(function) getInfo]
21:45:03 ハードウェア例外が発生しました
21:45:03 Exception : Access Violation(write access to 0x00564BEB)  at  EIP = 0x004057F2   ESP = 0x0012ED28   in D:\bin\dev\kr2\kirikiri2\krkr.eXe

何度かSystem.getKeyState()してから呼ぶと、ちゃんと（？）動作する。プラグインの作りが悪いんだろうな、きっと。

肝心の実行速度は、一回の取得につき約1/50000秒。TJS実装に比べて7〜8割速い。が、考えてみれば、ジョイスティックの状態なんてせいぜい1フレームに1回しか取得しないから、システム全体の実行速度からすれば誤差にもならない範囲。プラグインにする意味ないや。

昨日作ったプラグイン関数、見事にバグってた。とても恥ずかしいバグ。そりゃ、エラーになるわな。

線分を描画するプラグイン関数を作成。Layerオブジェクトを受け取って、C++からsetMainPixel()を呼び出す方式だと、TJSで実装したときよりも2倍くらい速い。さて…

今日のメインディッシュ。Layer.mainImageBufferForWriteで書き込み用バッファポインタを取得し、バッファを直接書き換える方式。これだと関数呼び出しのオーバーヘッドがなくなる分、格段に速くなる。前述の方式と比べて40倍以上速い。素晴らしい。

吉里吉里のLayer.mainImageBufferPitchのマニュアル。

((tjs_uint32*)((tjs_uint8*)mainImageBuffer + y*mainImageBufferPitch )) + x

じゃなくて、

(tjs_uint32*)((tjs_uint8*)mainImageBuffer + y*mainImageBufferPitch + x * 4)

ですね。

調子に乗って円を描画する関数も作る。これも劇的に速くなった。快適。

分けていた、算術系DLLと画像系DLLを一つにまとめた。ついでに、プラグインソース自動生成ツールも作る。

三角形を塗りつぶす関数と、円を塗りつぶす関数を作成。三角形の方は、三点をY座標でソートしてから水平スキャンするありがちな方法。円も基本的には水平スキャン。

実用的なレベルにはなってる…か？

角に丸みがついた矩形（何と呼ぶのかわからん。rounded rectangle?）を描く関数と、その塗りつぶし関数を作る。あまり速くない。仕方ないか。というか、あまり使い道がなさそうな気が。

ある多角形が、凸型か凹型かを判定するにはどうすればよいのだろう。

凹型多角形を複数の三角形に分割するにはどうすればよいのだろう。

射影変換のテスト。FF6の飛空挺のシーンみたいな、地面を上空から見るようなやつを作ってみたい。ちょうど、こんな感じのやつ…ちょっと違うか。

実装はC++で、吉里吉里にはDLLプラグイン接続。元画像、変換後の画像は共に二次元だが、一次元射影変換を組み合わせるだけでそれっぽく見えるので、とりあえず良しとする。640×480ピクセルの画像に対して変換してみたが、CPUへの負荷はほとんど無いようだ。

カメラの高度変更には対応しているが、カメラの方向変更には対応していない（回転機能がない）。これは後日、対応する予定。予定は未定。弱気。

Firefox/Netscape7用のLink Toolbar、ページに'Prev'や'Next'が記述されていないときに、'Prev'や'Next'になり得るURLを推測してサイトナビゲーションを作ってくれるのですが、現在のURLが http://xxx:8080/ のとき、

Prev

http://xxx:8079/

Next

http://xxx:8081/

となってしまいます。うーん、ポート番号を増やしたり減らしたりするのは、ちょっと違うんじゃないかと。

クォータービューのテスト。回転機能を追加し、ついでに空気遠近法らしきものを中途半端に導入してみた。実はちょっとインチキしているのだが、それらしく見えるので良し。

レイヤサイズが320*240だとすいすい動くんだが、640*480にしたとたんに重たくなってしまう。単純に計算量と描画領域が4倍になるから、仕方が無いといえば仕方が無いが。

射影のアルゴリズムをちょっと変更。パラメータの持ち方を工夫したので、多少融通が利くようになった。

クォータービューの処理速度をC++レベルで高速化。ループ中のif文をすべて排除し、重たそうな除算・乗算も極力排除。さらに演算精度をほどほどに保ちながら、計算回数を減らしてみる。

…んー、まだ重いなあ。剰余算が意外と曲者かも。

せっかくだから吉里吉里本体をリビルドしてみようと思ったが、どうも無理っぽい。ドキュメントに書かれているビルドに必要なビルド環境はC++Builder5だが、俺が持ってるのはC++Builder5.5（フリーのやつ）。上位バージョンなら大丈夫と思われがちだが5.5にはBCBが無いので .bpr をビルドできないみたい。BPR2MAK.EXEも内包されてない（ヘルプファイルに記載されてるのに…）ので、Makefileに変換することも出来ないし。C++Builder 5 って手に入るんだっけ？

そこで選択肢は二つ。

• C++ Builder 6 を導入
• BPR2MAKを作る

さて、どうするか。C++ Builder6でコンパイルできる保証は無いし、BPR2MAKを作ろうにもBPRとMakefileの書式を理解しないといけないし。

簡易マップエディタを作る。チップ一覧と実マップを表示出来ればいいや、程度のもの。