STG製作日記

ハッカーのたのしみ

2006-07-09T21:05:00.000+09:00

ハッカーのたのしみという本が面白いらしいので読んでみた。

本の冒頭に紹介されていたコードにちょっと疑問を感じたので、考えてみた。
それはasciiコードの'0'から'9'、'a'から'f'を入力して、対応する16進数を出力する
C2n(x)
　　{return x%87%48;}
というコードである。しかし、この場合だと剰余を2回使用している。つまり除算を2回使うことになり、計算コストが高い。また、'A'から'F'を入力した場合、正しく変換できない。

　'0'は、48なので2進で表すと、110000である。このビットの並びを眺めると、LSBの4ビット以外を0にしてやれば、0から9の数値が得られそうであることが分かる。つまり、x & 15とすることで、'0'から'9'という入力から数値の0から9が得られる。
　'a'から'f'の場合、x&15を計算すると、
'a'の場合、 1
'b'の場合、 2
'c'の場合、 3
'd'の場合、 4
'e'の場合、 5
'f'の場合、 6
となる。'a'は10なので、9だけ足りない。9を足してやれば求めたい答えになる。そこで、'a'の1100001の7ビット目をフラグとして使用することを考える。'0'から'9'では7ビット目は0であるが、'a'から'f'の場合7ビット目に1になる。7ビット目が1のときだけ9を加えればよい。9は2進数だと1001である。1のビットが２つある。1のビットが１つだけになるように、9を8+1に分解する。8は2進数で1000であり、1になっているビットが１つだけになる。1は2進数でも1なので、当然1のビットは１つだけである。
((x & 64)>>3)で、7ビット目が1のときだけ、8となる。
((x & 64)>>6)で、7ビット目が1のときだけ、1となる。
これを組み合わせて、
y = (x & 15) + ((x & 64) >> 3) + ((x & 64) >> 6);
というコードでasciiから16進数に変換することが出来る。このコードは、本で紹介されていた剰余を使うコードより高速だと思う。また、このコードの場合、'A'から'F'を与えた場合でも正常に変換することができるという利点もある。

関数ポインタを使って、配列に用意したx86コードを実行してみる

2006-07-04T23:35:00.000+09:00

#include ＜stdio.h＞

static int num = 0;

void op1(void){
　　printf("命令1を実行します\n");
　　num = 5;
}
void op2(void){
　　printf("命令2を実行します\n");
　　num *= 2;
}
void op3(void){
　　printf("命令3を実行します\n");
　　num += 2;
}
int main(void){
　　unsigned char *p;
　　unsigned char buf[100];
　　int j = 0;

　　// OP1のバイナリをbufにコピー
　　p = (unsigned char *)op1;
　　for (int i = 0; p[i] != 0xC3; i++) {
　　　　printf("%02X ", p[i]);
　　　　buf[j++] = p[i];
　　}
　　// OP2のバイナリをbufにコピー
　　p = (unsigned char *)op2;
　　for (int i = 0; p[i] != 0xC3; i++) {
　　　　printf("%02X ", p[i]);
　　　　buf[j++] = p[i];
　　}
　　// OP3のバイナリをbufにコピー
　　p = (unsigned char *)op3;
　　for (int i = 0; p[i] != 0xC3; i++) {
　　　　printf("%02X ", p[i]);
　　　　buf[j++] = p[i];
　　}
　　buf[j] = 0xC3; // RET(0xC3)を最後に付け加える
　　printf("\n");
　　
　　// 関数ポインタを定義
　　void (*fn)(void);
　　// bufの先頭アドレスをfnにセットする
　　fn = (void (*)(void))(&buf[0]);
　　
　　// fnを呼び出す
　　(*fn)();
　　
　　printf("num=%d\n", num);
　　return 0;
}

　うひょ～これはヤバいコードだぞ（笑）。でも動くんだなこれが。このプログラムでは何をしてるかといえば、bufという配列にx86のバイナリコードを書き込んで、それを実行している。しかも、x86のコードはあらかじめ用意してあるわけではなく、op１、op2、op3という関数のバイナリコードを使用している。
　op1、op2、op3関数のそれぞれの先頭アドレスから見ていって、RETという命令(16進であらわすと0xc3)が表れるまで、バイナリをbufに繋げてコピーしている。そしてbufを関数ポインタfnにセットして、fn()を呼び出すとop1、op2、op3を連続して実行したのと同じ結果が得られる。つまり、op1、op2、op3の3つを合成した関数が出来上がったわけである。これが意味するところは、スクリプトエンジンの仮想マシンの命令に対応する関数群を用意しておいて、それをスクリプトの記述に従って配列やmalloc等で用意した領域にコピーしていくことで、極めて簡単にスクリプトの記述をx86命令にコンパイルして実行できるということだ。
　まあ、最近のCPUだとこういうヤバイコードを実行するのを防ぐ機構（NXビットとかそういうやつ）がついていたりするはずなので、そういう環境だとこの方法では動かせないだろう。bufを確保する場所を、コードセグメントにすれば大丈夫かもしれないが、よく分からない。

各言語でベンチマーク

2006-06-24T15:59:00.000+09:00

StgScriptの構文は、ほとんどC言語と同じである。C言語と同様の構文を持つ言語は他にも色々ある。そこで、C言語、Java、JavaScript、StgScriptで同じプログラムを実行させてベンチマークを行ってみた。プログラムは、
xa = 0.0;
xb = 1.0;
s = 0.0;
eps = 1e-6;
k = 65536*32;
h = (xb-xa)/k;
for (i = 1; i < k-1; i++) {
　　a = xa + i * h;
　　a = 1-a*a;
　　x = 0;
　　do {
　　　　x++;
　　} while (a > x*x);
　　do {
　　　　x-=dx=(x*x-a)/(2*x);
　　} while (dx*dx > eps);
　　s += 4*x;
}
s *= h;
print_num(s);
こんな感じである。
StgScriptでは、print_num(s)が数字を画面出力する関数である。ここをそれぞれの言語にあわせて書き換える。実行結果は、
　　VisualC++の場合766[ms]
　　Javaの場合1011[ms]
　　STG Scriptの場合12427[ms]
　　JavaScriptの場合83640[ms]
となった。
まとめると、
　　VisualC++のコードは、Javaのコードより、約1.3倍速い
　　Javaのコードは、STG Scriptのコードより、約12.3倍速い
　　STG Scriptのコードは、JavaScriptより、約6.7倍速い
という事になる。これを例えるならば、
　　JavaScriptは、徒歩
　　STG Scriptは、原付自転車
　　Javaは、新幹線
　　VisualC++は、ゼロ戦
という感じだろうか。

MIPS値を計測する

2006-06-22T15:43:00.000+09:00

スクリプトエンジンの実行速度がどの程度なのか気になったので、計測してみることにした。何度もループするようなスクリプトを実行させて、実行時間と実行した命令数（仮想マシンコードの命令数）をカウントする。実験に使うスクリプトは、円周率を計算させるプログラムである。　実行結果は、
　　　Instraction count = 244444609
　　　Time = 10785[ms]
　　　MIPS = 22.6652[MegaInstraction/sec]
という数値になった。つまり1秒間に0.22億回命令を実行している。ちなみにこの数値を計測したPCの環境は、
　　　Intel PentiumIII Coppermine
　　　L1 I-Cache 16KB
　　　L1 D-Cache 16KB
　　　L2 Cache 256KB
　　　Internal Clock 600MHz
　　　System Clock 100MHz
という感じである。CPUのクロックが600MHzで22MIPS実行できたということなので、このスクリプトエンジンは速くはないが遅くも無いといった感じだろうか。システムの機能が完成してきたら、この辺はもうちょっと最適化を行いたいと思う。現状だとfloatからintへの型キャストがかなり多いのが一番のネックだろう。スタック領域とコード領域を64bit境界でアラインさせるとか、いろいろと最適化のポイントは残されていると思う。

スクリプトの言語仕様

2006-06-21T17:49:00.000+09:00

スクリプトの言語仕様を見直しました。

１、変数の宣言を不要に
　BASICやJavaScript風に変数の宣言を書かなくても良いことにしました。 int hoge;等としなくても変数を使えます。

２、=で変数へ代入を行うと、それが宣言の代わりとなる
　hoge = 100;という具合に、代入を行ったときに変数が定義されます。代入を一度も行っていない変数の左辺値を使おうとするとコンパイルエラーになります。たとえば、
　　a=100;
　　a=a+5;
　　b+=5;
　　a=a+c;
と書いた場合は３行目と４行行目がコンパイルエラーになります（bとcが初期化されていない為）。これによって、未初期化の変数に対してアクセスしてしまうことを防ぎます。また、変数名をタイプミスした場合でも結果的にコンパイルエラーになることが期待できます。変数の宣言無しの言語では、TYPOが発見しずらいという問題があるのですが、「代入を行ったときに変数が定義される」というルールにすることで、TYPOをコンパイルエラーとして検出することが出来ます。例えば、
　　hoge=100;
　　hogu++;
と記述してしまった場合（２行目をタイプミスしている）でも、コンパイル時にエラーが報告されます。このような間違いの場合でも、古典的なBASICではそのまま実行されてしまいます。しかし、
　　hoge=100;
　　hogu=hoge+1;
と書いた場合では、このスクリプトでもそのまま実行されてしまうので完璧ではありません。

３、明示的に変数の宣言を書くことも出来る
　var hoge;で変数hogeの宣言ができます。初期化を省略した場合、0で初期化されます。

４、組み込み関数の追加
ジョイスティックの状態を返す関数
　　　stick_x()、stick_y()
ボタンの状態を返す関数
　　　botton()
プレイヤー位置を返す関数
　　　get_px()、get_py()
プレイヤー位置の方向に向きを変える関数
　　　look_at_player()
スクリプトの実行を終了する関数
　　　 destroy()
BGMを再生する関数
　　　play()
効果音を鳴らす関数
　　　sound()
得点を加算する関数
　　　add_score()

　変数や関数の名前が、いまいち統一感が無い感じがします。初めの頃に作った変数はキャピタライズされていますが、最近作った関数は全部小文字＋アンダーバーになっています。ここは全体的に見直す必要があるかもしれません。

VisulalStudioExpressEditionに一本化

2006-06-18T19:34:00.000+09:00

STGの本体のプログラムは、VisualStudio Express Editionで開発していたのだが、スクリプトコンパイラはVisualC++6.0で開発していた。この二つのバージョンのVisualC++はうまい具合に同居できたので、同時に立ち上げて開発したりしていた。古めのPCで開発環境を構築しようと思ったのだが、VC6.0とExpressEditionの二つとPlatoformSDKとDirectXSDKをインストールすると、かなりディスクスペースを食うので、ロースペックなPCではきついものがある。しかたないので、ExpressEditionでも開発できるようにスクリプトコンパイラのソースコードを修正した。古い形式の関数を呼び出している部分を全部修正しようかと最初は思ったのだが、
#define _CRT_SECURE_NO_DEPRECATE
っていう一行を書いておけばとりあえずWarningの嵐はおさまるので、書き換えは最小限で済ませることにした。これで一応は、ExpressEditionだけあれば開発できるようになった。

ガンマ補正

2006-06-15T16:12:00.000+09:00

Windows2000の環境で、STGを起動したら画面が真っ黒だった。しかし音は出ている。特に問題となるようなデバックメッセージも出ていない。グラフィックカードがへぼいから画面が出なくなるんだろうかと一瞬思ったが、よーく目を凝らして画面を見るとかすかにキャラクタらしきものが動いているのが見えた。ほとんど真っ暗なんだけど、液晶を斜めから見たりするとうっすら見える。これはプログラムに問題があると思い、ソースコードを眺めたりしていたのだが、原因がさっぱりわからなかった。　テクスチャ画像（PNG形式）をなにげなくクリックしてみたとき、変なことに気が付いた。表示されたサムネイルが真っ黒だった。XPの環境では普通だったはずなのに。PNGの画像がおかしいか、Windows2000のPNGをデコードするAPIとかがおかしいかのどちらかである。このPNG画像から怪しいニオイがプンプンしたので、とりあえずPNGのヘッダ情報を見てみることにした。ちなみに使用したソフトはhttp://entropymine.com/jason/tweakpng/にあったものを使わせていただいた。　そうしたところ、ガンマ値が0.0に設定されている。これは怪しい。これを0.4にしたところ正常に表示されるようになった。このPNG画像を作るためにPhotoShop5.0を使ったのだが、これのPNG出力はどうやらダメダメなのかもしれない。

DirectX

2006-06-12T10:27:00.000+09:00

STGのコア部分がようやく出来上がってきたので、いろいろな環境（会社のPCとか、会社のPCとか）で動作確認を行ってみた。まず大前提として、今回のプログラムはDirectX9が動く環境で動作する。よってOSはDirectX9が動作するものに限定される。具体的にはWindows98以降ならDirectX9がインストールできるので、開発中のSTGも動く可能性がある（しかし、しょぼいディスプレイドライバしか無い等の理由で、DirectX9がインストール出来たからといって、開発中のSTGも必ずしも動くとは限らない）。
　まず、Windows2000で動作テストしてみる。しかし、起動せず。d3dx9_29.dllが無いと怒られる。DirectX9cのランタイムはインストールしてあるのに何故？というわけで検索してみると、d3dx9_29.dllはDirectX 10.0 (February 2006)に含まれているらしい(参考ページ：http://www.nbrains.net/php/pukiwiki/index.php?link%BD%B8%2FDirectX)。同じDirectX9でもバージョンがたくさんあってややこしいことになっている。仕方なくDirectXのランタイムをバージョンアップすると、とりあえずSTGのプログラムは起動した。しかし、会社のマシンはサウンドカードが入って無いので、サウンド関係の初期化処理の部分から先に処理が進まなくなる。サウンドカードが入ってないPCなんかサポート外という仕様にしてしまってもまあ、問題ないかと思うが、一応サウンドドライバが無い環境では、この辺の処理を自動的にスキップするようにしないとまずいと思った。また、文字コードの関係で問題が出る。UNICODEを使用してプログラムを開発していたのだが、Windows2000のWin32APIでは対応していない部分もある様である。デバックメッセージの出力などがうまく動いていない。また、Windows98、Windows98SE、WindowsMEは、UNICODEのAPIはほとんど実装されていないらしく、全滅である（WinMainで最初に行う処理である、RegisterClassがUNICODE対応していない為に失敗する)。UNICODE用にプログラムを書き換える前の古いバージョンのプログラム（S-JIS用)では、Windows98でも動作した。Windowsアプリケーションの開発でUNICODEを何も考えずに使うと、動作するOSがWindowsXPに限定されてしまう様である。Windows2000や98でも動作するUNICODE関連のAPIだけを使うようにすれば、それらのOSでも動作させることが出来るが、面倒な話である。今回のSTGの場合、ゲーム本編では2バイト文字を扱うような部分は存在せず、デバックメッセージ等で2バイト文字を使っているだけである。それだけのために動作するOSがWindowsXPに限定されてしまうのは本末転倒な話である。
　動作確認の結果をまとめると、
1、ターゲットとするDirectXのバージョンを明確にする
2、XP以外も動作保証するならば、文字コードをS-JISにする
3、サウンドカードの無い環境では音関係の処理をスキップする
以上3点の改修を行う必要がある。意味もなく新しいバージョンのDirectXが必要になるようにした場合、このプログラムを動かそうとしたエンドユーザから動作しないというクレームがくるはめになりそうである。DirectX9C以後なら、動作するようなバージョンで開発するべきだと思った。d3dx9_29.dllとかは、DirectX9SDKに含まれているのだが、DirectX10におけるDirect3DのTechnology Previewっていう位置付けのものらしい。DirectX10がちゃんとサポートされるのはWindows Vista以後らしい。

ひさしぶりに

2006-06-10T17:18:00.000+09:00

コーディングは間が空いてしまうと、どんどんやらなくなってしまう。一ヵ月も時間が経つと自分のソースコードも他人の書いたのと同じようなものであると思う。VisualC++を立ち上げても、ソースを解析するところから始めなければならない。そんなときに、自分が書いたBlogを読んでみると思考の過程を知ることが出来るので、コードを組むときに考えていたことを思い出すことができる。最近忙しくてなかなか時間が取れないが、思いついたことを無駄にしないように、Blogにメモとして残しておきたい。
generate(),texture(),child()等の組み込み関数のparse処理を行っている関数は、parser.cpp内の parse_function()である。そのparse_function()では、typeという変数にパースした関数の種類が格納されるので、それを見てスクリプトリストを書き出す処理を加えれば良い。
generate("filename")の"filename"という文字列リテラルは、parse_expression()でパースされる。現状では、node = make_node(type, parse_expression(), null); というコードで構文木を作っているので、この処理を分割してparse_expression()の左辺値を変数に取っておく。現状では、nodeは expressionであれば、コンパイルが通ってしまうので、typeが示している組み込み関数の引数として、node->typeの種類が正しいかチェックする必要がある。具体的には、
switch (type) {
case T_GENERATE:
case T_CHILD:
if (node->type == T_STRING) {
//構文木を作る処理
} else {
// コンパイルエラーのメッセージを出す処理
}

のような処理が必要になる。generateとchild関数は、引数にstring型の変数を１つだけ渡せる関数なので、このようなチェックを行い、ifの条件がtrueにならなかった場合はコンパイルエラーにしなければならない。
int list_set(char *key)という関数に、スクリプトのファイル名をキーとして渡してやり、int型のユニークな番号を戻り値で受け取る。具体的なコードは、
unique_num = list_set(node->str);
である。list_set()では、呼ばれるごとにスクリプトリストのファイルを開いて、なかにkeyと同じ行が無いか探す。同じ行が見付かった場合、その行番号を返す。見付からなかった場合は、スクリプトリストの最後の行にkeyを追加して、その行番号を返す。その行番号がスクリプトのファイル名に対応するユニーク番号となる。
受け取ったユニークな番号を構文木に埋め込む処理であるが、まずnode-typeがT_STRINGになっているのをnode-> type = T_NUMにする。そして、node->dbl_num = unique_numとして、スクリプトのファイル名をユニークコードで置き換える。

コンパイル時間

2006-04-09T18:11:00.000+09:00

それにしても、C++側のソースコードのコンパイルに時間がかかるようになってきたなあ。およそ３分ぐらい待たされる。逆に、スクリプトコンパイラのソースコードのコンパイル（ってややこしいな）は、あっという間（５秒ぐらい）で終わる。スクリプトコンパイラではC++のリッチな機能を使わずに組んであることが、コンパイル時間が短い理由だと思われる。
　もし、敵キャラクタのアルゴリズム等もC++側で作りこんだ場合、ソース修正のたびに３分も待たされたらけっこう大変だと思う。その意味では、スクリプトエンジンを組み込むという構想は成功しているのかもしれない（でも、スクリプトエンジン自体のデバッグがかなり大変なんだけどね・・・）。

ジャンプ命令

2006-04-09T16:36:00.000+09:00

スクリプトの命令セットには分岐関係の命令が3つある。条件無し分岐のJMP、スタックが０以外な分岐するJNE、スタックが０なら分岐するJEの３つである。分岐先のアドレスだが、現在は３２ビット値で指定するようになっている。しかし、スクリプトなのでそんなにアドレス空間は広くする必要もない。相対ジャンプなら、-128から127の範囲でジャンプできればほとんどの場合大丈夫だろう。その方がコードサイズが小さくなる。というわけで、ジャンプ先のアドレスを8ビット、16ビット、32ビット、それぞれのサイズで指定できるように命令を追加した。

超CISC

2006-04-08T20:12:00.000+09:00

スクリプトコンパイラの出力するバイナリコードのニモニックは、1バイトのサイズである。仮想マシンのような構造であるスクリプトインタプリタだが、それ用のニモニックは単なる識別子としての役割しかないため、０～２５５の範囲に自由に割り当てることが出来る。ハードウェアのCPUに与えられるニモニックは、CPUの制御回路に与えられる制御信号であるため、仮想マシンのニモニックの様に自由に割り当てることはできない。
　スクリプトインタプリタの命令セットは、なるべく多機能にするのが良い。その方が高速化できる可能性があるからだ。RISCの場合は命令セットを単純化して、その代わりに1つの命令を高速に実行できる機構を持っている。スクリプトインタプリタの高速化は、RISCとはまったく逆のアプローチと言える。命令をなるべく多機能にして、1回の命令実行で行える処理を多くするわけである。これを私は超CISCと名づけた。
　というわけで、超CISCの思想に基づいて、命令をいくつか追加した。バイナリサイズをなるべく小さくするために、
push_imm_byte
push_imm_word
push_imm_dword
push_imm_float
という命令を追加した。また、０や１という数値はプログラム中でよく現れる値なので、専用の命令
push_imm_0
push_imm_1
というのも作ってみた。これによって、コードサイズは半分程度に激減したようである。

　

最適化

2006-04-07T22:10:00.000+09:00

optimizerをちょっと改良した。optimizerってのはコードの最適化を行う、スクリプトコンパイラのモジュールである。 C言語の場合だが、以下のように、意味の無い式を書いてもコンパイルは通る。
void main() {
　　int a;
　　a;
}
この場合、a；だけの式は何もしない式である。これに対してコード生成を行うのは無駄である。しかし、今までスクリプトコンパイラはこのような意味の無い式に対してもコード生成を行っていた。
int a;
a;
と記述した場合、
push a
pop
というコードが出力されていた。つまりaの中身をスタックにプッシュするが、その後何もせずにpopするわけである。このような意味の無い式を検出して、削除するようにoptimizerを改良した。これで余計なコードが減るので、出力されるコードサイズがけっこう小さくなった。

スクリプトリスト

2006-04-04T18:52:00.000+09:00

えーと、下2回で書いた内容はやっぱやめ（笑）。もっとシンプルな方法でいこう。ハッシュとか使うと複雑になりすぎるね。
まず、スクリプトリストについて。これはスクリプトのファイル名が列挙して書いてあるテキストファイルである。スクリプトのファイル名というのは、バイナリファイル名じゃなくて、ソースファイル名にする。また、スクリプトリストの生成を行うのは、スクリプトコンパイラの役目とすることにした。スクリプトコンパイラは以下のような手順でスクリプトリストを作る。
１、スクリプトリストをロードする。
２、コンパイルするソースファイル名が、スクリプトリスト中に含まれるかどうかをチェックする。含まれて居た場合３へ、含まれて居ない場合は４の処理へ。
３、ソースファイル名がスクリプトリストに含まれていたのが何行目かを変数に保存しておく。
４、スクリプトリストの末尾にソースファイル名を追加して、その行番号を変数に保存しておく。
この処理を経て、変数に行番号が入るわけである。この番号を、そのスクリプトのユニークコードとして用いる。この方法ならば、連番になっているユニークコードとなる。ハッシュで生成したユニークコードでは得られない性質である。
例として、test.txtにおいて以下のような記述がされている場合、
//text.txt
x = 10; y = 20;
generate("enemy1.txt");
frame(10);
generate("enemy2.txt");
このコードをコンパイルすると、スクリプトリストは以下のように生成される。
text.txt
enemy1.txt
enemy2.txt
これは、text.txtを0、enemy1.txtを１、enemy2.txtを２という、ユニークコードを割り付けたことになる。

double撤廃

2006-04-02T20:53:00.000+09:00

バイナリ中に埋め込まれる定数を、doubleからfloatに変更した。doubleは8バイト、floatは4バイトなので、コードサイズがけっこう小さくなった。また、余分な型キャストの回数が減ったので、スクリプトの実行速度が速くなったかもしれない。この修正作業は、スクリプトコンパイラのソース中の"double"という文字を"float"に全部置換した。何も考えず置換を行ったが、うまくいったようだ（笑）。

TODO　その３

2006-03-31T19:49:00.000+09:00

カラーキーだが、普通は何色をカラーキーにするものなんだろうか。まあ何でもいいのだと思うが、0x00FF00(原色の緑）とかでいいのかな。あんまり目には優しくない色だけど（笑）。下では、スクリプト中でカラーキーを指定できるようにしたい、と書いたが、スクリプトはなるべく簡単に書けるのが理想なので、カラーキー指定をスクリプト中でやるのはやっぱり止めようかな。ロードした画像の一番左上、つまり(x,y)=(0,0)の色を調べて、それが０ｘ００ｆｆ００だったらカラーキー有りとする。それ以外の色だった場合は、カラーキー無しとすれば良いような気がする。これならカラーキーの色をいちいち指定しなくてもいいので楽だ。
　スクリプトからスプライトは生成されるわけだが、STGの場合はスプライトの生成と消失を何度も繰り返すわけで、ここの処理は高速に行えないとまずい。スクリプト中では、スプライトの生成をgenerate("filename.bin")という記述で行うつもりである。スクリプトのファイル名を指定しているわけだが、generate関数が呼ばれるたびにファイルを読みに行くような実装では、STGでは使い物にならない。
　ところで、generate関数と同様なインタフェースを持つ関数として、texture関数がある。これもファイル名だけを指定すれば、あとは勝手にシステム側がうまく処理するという設計思想に基づいて作ってある。texture関数の場合、ロード済みのテクスチャのファイル名のmap（連想配列）を内部に持っていて、それを使って、いまtexture関数で指定されたファイル名がすでにロードされているか、されていないかを調べる。この仕組みによって、同じテクスチャを重複してビデオメモリにロードしてしまうのを回避している。この仕組みをスクリプトのロード時にも行えば良いと最初は思っていたのだが、mapに登録されているか否かを調べるのは、スプライトの生成毎に行う処理としては重すぎるように思う。
　この問題を解決する方法として、プログラムの起動時に全てのスクリプトを読み込んでしまう設計にしようと思う。テクスチャと違って、スクリプトは１つのファイルが大きくても1kb程度なのでメモリ使用量は対したこと無い。全てのスクリプトを前もってロードするためには、*.binというファイルをプログラム起動時に検索するという手段も考えられるが、これは実装が面倒くさいと思う。全スクリプトのリストが用意してあればプログラムとして実装するには楽だ。全スクリプトのリストというのは、
player.bin
enemy1.bin
enemy2.bin
tama1.bin
.
.
.
という単にファイル名が1行ごとに書いてあるテキストファイルにしようと思う。プログラム起動時に、このリストを見てスクリプトをロードしていくわけである。このリストは手作業で書いてもよいと思うが、バッチファイルで作るようにすれば簡単だろう。スクリプトコンパイラは、generate("test.bin");という記述に対して、"test.bin"からユニークなコードを生成して、ファイル名の代わりに埋め込むようにしようと思う。不定長の文字列から、固定長のユニークコードを生成するには、ハッシュ関数を使うのが普通だと思う。プログラム起動時に、スクリプトのリストにしたがってスクリプトをロードしながら、そのファイル名のユニークコードを作成する。そうすれば、バイナリ中に埋め込まれたユニークコードが何のファイルを指定したものなのか、判別することが出来る。このハッシュ関数のアルゴリズムだが、さすがにMD５とかを持ってくるのは大げさなので、簡単な方法を自分で実装しようと思う。できればコリジョンが無いアルゴリズムに出来れば楽なんだけどな・・・

TODO　その２

2006-03-30T23:05:00.000+09:00

カラーキーをスクリプト中で指定できるようにしたい。ファイル名の後にR,G,Bを指定して、
texture("filename.png", R, G, B);
の様にすればいいと思う。しかし、カラーキーの色は全部の画像ファイルで統一してあれば、固定でもかまわないわけで、
texture("filename.png");
とカラーキーを省略した場合、デフォルトとして指定してあるカラーキーの値を使うことにしよう。カラーキーが要らない場合は、
texture("filename.png", 0, 0, 0);
と全部に0を指定することにしよう。
　スプライトの速度(vx,vy)を指定したら、その速度ベクトルの方向に対してテクスチャの絵が正面が向くように、自動的にスプライトが回転してくれたら楽だ。速度から、自動的にスプライトの角度を設定する関数、
AutoRotation();
みたいなのを作ろうかと思う。詳細は後から考えよう。
　プレイヤーの座標がスクリプトから得られないのでは、かなり問題がある。そこで、
GetPlayerX();
GetPlayerY();
ってのが必要だろう。
　あとは、BGMや効果音をスクリプトから制御する関数も必要だ。インタフェースは単純に、
PlayBGM("hoge.ogg");
PlaySound("fuge.ogg");
PlayBGMLoop("hoge.ogg");
みたいなのがよろしいかと思う。関数の多重定義風に、
PlayBGMLoop("hoge.ogg", A, B);
でABリピートするようにしよう。AとBには何を指定すればいいのかは分からないので、NPK氏に後で聞いておこう。

またスプライトクラスの設計修正

2006-03-30T22:10:00.000+09:00

またちょっと、スプライトクラスの設計を修正した。こんなことを何回やってるんだろうか（笑）。最終的に、スプライトクラスが全てのクラスの中心的役割を担うようになった。ゲームの進行に関係ある変数を保持しているのは、スプライトクラスだけである。どのテクスチャとスクリプトを使用しているか、という情報もスプライトクラスが保持している。テクスチャクラスとスクリプトクラス側からは、どのスプライトから参照されているか、というのは知らないわけである。
　スプライトクラスは、自分のペアとなるテクスチャやスクリプトを選びたい放題の八方美人である。いろんなテクスチャやスクリプトと関係を持つ節操が無いクラスである。もはや貞操観念というものが抜け落ちている。しかし、スプライトクラスは、一度関係を持ったクラスには、自分の全てを捧げるという、また違った一面も持っている。

//スプライトに関連づけされた、スクリプトを実行する
void Sprite::ExecuteScript()
{
　　　//私(this)の全てを捧げます
　　　　script->Execute(this);
}

これで、スクリプトは、スプライトを思うがままに出来る。

文字コードとか

2006-03-30T10:12:00.000+09:00

スクリプト中では、単にテクスチャ等のファイル名を指定しておくだけでよく、リソースの管理などはしなくて良い構造にしようと思っている。具体的には、テクスチャは以下のようにして指定する
texture("filename");。
当然、同じテクスチャを複数のスクリプトで使う場合もある。単純にスクリプトで指定されたテクスチャのファイルを毎回ロードしていたのでは、あっという間にビデオメモリを消費し尽すだろう。texture関数は、ロード済みのテクスチャを覚えておいて、重複してテクスチャをロードしてしまうことを回避するような構造にする必要がある。これを実現するために、STLのmapを
map＜string, IDirect3DTexture9*＞ fileName2Texture;
と定義して、ファイル名とテクスチャへのポインタの対応表を作ろうとした。しかし、wchar_tでファイル名は与えられるが、それをstringに変換してくれるようなstringの代入演算子やコンストラクタは用意されて無いっぽい。どうしたらいいか分からなくて困っていたら、ワイド文字列版のstringであるwstringが有るらしいので、wsrtingを使うことにした。しかし、今度はwstringで
map＜wstring, IDirect3DTexture9*＞ fileName2Texture;
とやろうとすると、コンパイラが文句を言ってくる。STLのソースコードの行番号を表示して、定義を確認してくださいとかほざくのである。そんなの無理です（笑）。いい加減、ワイド文字列で処理するのが面倒になってきたので、UNICODEからマルチバイト文字に変換するWinAPIで変換してしまおうか、という考えが頭をよぎる。しかし、テクスチャを指定するたびに、文字コード変換するAPIを呼ぶのはいかがなものだろうか。多分、文字コード変換は軽い処理では無いはずだ。スクリプトエンジンのパフォーマンスに影響を与えるに違いない。あーめんどくせー。

スタックオーバーフロー

2006-03-30T01:40:00.000+09:00

スクリプト実行時に、スタックオーバーフローと無限ループに入ってしまう場合があるバグが直った。原因はコード生成するルーチンに抜けがあった為だった。バグは比較演算子の!=などで発生していた。parserは!=のトークンに対して、T_NEという識別の為の定数をもつ構文木のノードを作る。しかし、T_NEノードに対して適切なコードを生成する部分を、code generatorに追加するのを忘れていたようだった。結果として、!=は無かったのと同じことになってしまっていた。私は、あまり!=を使わないでプログラムを書くので、今までこのバグが発覚しなかった様だ。
　例えば、擬似的な表記ではあるが、
if (A!=B) { L1: ...} else { L2: ...}
という記述から生成されるコードは、
push A
push B
sub
je L2
L1:
...
L2:
...
こんな感じになる。今回のバグの場合、!=に対してのコード生成が行われなかった為、
push A
push B
je L2
...
L2:
...
このようになっていた。subが無い場合スタックからAの値がpopされないままになってしまう。また、je L2では、Bが０か？という判定だけを行い、L2に飛ぶので場合によっては無限ループになっていたわけである。

変数の宣言　続き

2006-03-29T11:34:00.000+09:00

下で書いた通り、C++風にどこでも変数の宣言が出来るように、スクリプトコンパイラを修正した。これでちょっとだけスクリプトが書きやすくなった。

変数の宣言

2006-03-29T10:17:00.000+09:00

STGスクリプトの、プログラムは、ブロック、である。
なんだか意味が分からない文章だが、BNF記法風に書くならこうなる。
<プログラム>:=<ブロック>
さらに、ブロックは、宣言リストか、文か、ブロックの繰り返し、である。
<ブロック>:=<宣言リスト>|<文>|<ブロック>*
ブロックっていうのは、{ }で囲まれた部分のことであり、宣言リストというのは、int x; float f; char str;などと、宣言が並んでいる部分のことである。
　現状の実装の場合、STGスクリプトでは、宣言はブロックの先頭でのみ行うことができる。しかし、ブロックはブロックの中にいくつでも作れる。つまり、ブロックを作ってやれば、いつでも宣言が出来ることになる。宣言がブロックの先頭でしか出来ない、というのはC言語と同じである。C++になると、宣言はどこでも出来るようになった。このSTGスクリプトの場合、変数のスコープというものが無いので、ブロックの先頭でしか宣言が出来ないという制限を与える意味も無いかもしれない。ここはC++風に改めた方がいいかもしれない。

スクリプトSDK

2006-03-29T03:15:00.000+09:00

現時点で出来上がっている、スクリプト開発用のツールとドキュメントをまとめた。サンプルを見れば、おおよその記述方法は分かると思う。
http://park19.wakwak.com/~usapyon/ScriptSDK.zip

スクリプトのバグ？

2006-03-28T21:08:00.000+09:00

スクリプトコンパイラもしくはインタプリタにあるバグの原因を突き止めやすくするために、スクリプトコンパイラの生成するバイナリに、トレース情報を埋め込むオプションをつけた。ここで言うトレース情報とは、単純にソースコードの行番号を、ソースのセンテンス（文）が終わる部分（このスクリプトの場合、文の終わりは;で示している）で出力しているだけである。そのようなオプションが必要になったのには理由がある。特定のスクリプトを実行した場合に、無限ループに陥る上に、スタックオーバーフローを起こす場合があることが判明した。そのバグは必ず発生するわけではなく、スクリプトの記述をちょっと変えたりすると再現しなくなる。バグを起こすスクリプトの記述の仕方には、想定している文法上では無限ループになったりするような部分は無い。また、スタックオーバーフローを起こすような長い計算式も無い。よって、この原因は、スクリプトコンパイラかスクリプトインタプリタのバグだろう。
　このようなバグの原因を探すのは難しい。今までは、コンパイラが出力したコードを逆アセンブルして、アセンブリコードを頭の中で実行してみて、コンパイラのバグを探すしかなかった。今回の修正で、トレース情報をバイナリに埋め込むことが出来るようになったので、スタックが溢れつつある場合には、そのときのインストラクションポインタ、スタックポインタ、ソースの行番号をコンソールへ出力できるようになった。これでデバック効率がずっと良くなる。
　例えば、以下のようなコードをコンパイルして、
float a, b, c, d;
a = b + c * d;
生成されたコードを逆アセンブラにかけた場合、出力されるアセンブリコードは、
push [19]
push [21]
push [20]
mul
add
push 18
store
pop
である。push [19]という命令は、メモリの19番地の内容をスタックにプッシュする。この場合、コンパイラはfloat型の変数bを１９番地に割り当てたわけである。続いて、cとdも順にプッシュされる。mulは、スタックから２個の値をポップして、その２つの値を乗算した結果をスタックにプッシュする。addはmulと同様に、スタックから２個の値を取り出して、加算した結果をプッシュする。push 18は、変数aのアドレスである18を、スタックにプッシュする。storeは、スタックから最初にアドレスをポップして、次に書き込むデータをポップする。そして、そのアドレスとデータを使って、メモリに書き込む動作をした後に、データをスタックに戻す（プッシュ）する。これは、その計算式の右辺値を使う場合に必要になるからである。このコードの場合は、計算はここで終わりで右辺値は使用していないので、最後にpopされて、そのデータはスタックから捨てられる。
　このように、１つのセンテンスを実行すると、スタックポインタは０に戻るのが普通である。スタックポインタが何らかの原因で０にならなかった場合、それがループ中だったらいつかスタックオーバーフローを起こすのは自明である。つまり、１つのセンテンスの中でスタックにプッシュした回数と、ポップした回数は等しくなければならない。等しく無い場合は、コンパイラのコード生成のどこかでミスをしているはずだ。

関数が作れないC言語

2006-03-28T13:38:00.000+09:00

今作成中のスクリプト言語を一言で説明するならば、「関数が作れないC言語」となるだろう。基本的にはC言語になるべく似せるように設計した。HSPの様に独自の言語体系になってしまうと、スクリプトを書く人が言語を覚えるのが大変だろうということで、慣れている人が多いと思われるC言語に似せることで、覚えなくてはいけないことを減らそうという考えがあった。
　しかし、このスクリプトとC言語では差異がかなりあるのも事実である。変数は基本的に全てfloatだけである。double、int、long、charの変数を定義してもエラーにならないし変数も普通に使えるが、その変数の実態はfloatである。int num;と定義した変数に対して、num=0.5;と記述してもエラーにならないので気をつけないといけない。また、ループ脱出構文も用意されていない。breakとcontinueは実装するのが面倒そうだったので入れるのを止めた（笑）。さらに、gotoも無いので、ループを途中で抜ける手段はまったく無いわけで、場合によっては不便かもしれない。後でgotoぐらいは実装するかもしれない。ループ構文には、for(,,,){ }、while( ){ }、 do{ } while(); が使用できる。switch( ) { case }は便利な構文であるが、これも実装が面倒そうなので、実装していない。if () { } else if () { } という書きかたは出来るので、それでswitchの代わりにすることになる。また、配列変数、ポインタ変数、構造体も使えない。
　演算子についてであるが、使用できる変数の型がfloatだけであるので、ビット演算の演算子は全て使えない。具体的には&、|、<<、>>、＾などが使用できないビット演算子である。マニアックなところでは、条件演算子の? :や、コンマ演算子も使用できない。float a, b, c, d;という記述は出来るが、これのコンマは、コンマ演算子としての実装ではない。

演算子など追加

2006-03-27T23:31:00.000+09:00

このスクリプトには、実は論理演算のAND、ORが無かった。つまり、C言語の＆＆と｜｜のことです。実装したつもりでいて、実装してなかったらしい。先日、スクリプトをコンパイルしようとして、
ｉｆ（ｘ＜０　｜｜　ｘ＞＝６４０）｛
という部分で、なぜかエラーが出るのでソースを見直したら、実装してないことに気が付いた（笑）。

可読性に欠けるが、上記のコードについて、&&と||を使わなくても、
if（（ｘ＜０）＋（ｘ＞＝６４０）｛
でも、等価な動作をする。また、論理を反転して
if（ｘ＞＝０　＆＆　ｘ＜６４０）｛
または
if（（ｘ＞＝０）＊（ｘ＜６４０））｛
でも同じことが記述できる。
そういう書き換えを使って、&&と||無しを仕様ということにしてしまうおうかと思ったが、分かりづらいので、&&と||も追加することにした。
　昨日から、スクリプトコンパイラにたくさん機能追加したので、色々なソースを食わせてみてテストをおこなってみた。きわどい記述のソースコードをコンパイルしてみて、バグ出しをするわけである。それで気が付いたのが、演算子の優先順位がＣ言語とはちょっと違ってしまっていることだ。Ｃ言語では、
if (a || b && c) {
というコードがあったら、&&が先に評価されるようになってたはず。このスクリプト言語の場合は、||と&&は優先順位が同じにしてしまったので、このコードの場合、左から順に評価される。つまり||が先になる。
まあ、このコードのようなきわどい記述は普通しないので、問題にならないとは思う。とは言っても、このような細かいバグが全体に散らばってるので、直していかないとなあ。

ＴＯＤＯ

2006-03-27T18:13:00.000+09:00

今のスクリプトコンパイラはdoubleを基本としたコードを出力する。バイナリ中に埋め込まれる定数も、基本的に全部doubleだ。これは元々、このスクリプトコンパイラはゲーム用に使うことを想定していなかったからである。ゲーム本体側のプログラムではDirect3Dを使う関係で、浮動少数点の変数は全てfloatにしてある。スクリプトインタプリタは元々はdouble用だったのだが、小手先の修正を行って、バイナリからロードする部分でdoubleからfloatに変換を行い、後の演算はfloatで行うようになっている。型のキャストというのは結構、処理時間を食うものなので、スクリプトコンパイラもfloatを使うように変更するべきだと思う。定数１個で、8byteもバイナリサイズを食うのも良くないしね。スクリプトコンパイラのソースコード中に出てくるdoubleという文字を、置換でfloatに全部置き換えたら、うまく動いてくれないかな・・・
　後、当たり判定のことをすっかり忘れていたのだが、どういう仕組みにしようかなあ。まあ、スクリプト側では当たり判定のことを気にしなくても、画面外に出たりすると勝手にキャラクタが消失してくれるような仕組みがいいと思うんだけど、やってみないと分からない部分が多いな。

組み込み関数の実装

2006-03-27T06:34:00.000+09:00

文字列リテラルの処理を追加しようとコードを弄ってるうちに、ちょっとずつスクリプトコンパイラ細部の設計を思い出してきたので、組み込み関数の追加はあっさり出来た。追加した関数は以下の通り。
generate("FileName.bin") FileNameというファイル名のスクリプトを実行する
child("FileName.bin") FileNameというファイル名のスクリプトを子として実行する
texture("FileName") FileNameというファイル名の画像をテクスチャとして設定する。
frame(n) ゲームをnフレーム進める。
abs(x) xの絶対値を求める。
sin(x) xのsinを求める。
cos(x) xのcosを求める。
toint(x) xの小数部を切り捨てる。
print("string") stringをデバックメッセージとして、コンソールに出力する。
今の所はこんな感じである。ちなみに、これらの関数はスクリプトエンジンの命令セットの１つの命令としてコンパイルされる。スクリプトエンジンの命令セットは、１バイト固定長なので、２５６種類の命令を定義できる。命令の種類はまだ４０個ぐらいしかないので、ガンガン命令を追加しても大丈夫だ。

文字列

2006-03-27T02:02:00.000+09:00

自分の昔のコードを解読（笑）し、何とかスクリプトコンパイラが文字列を扱えるように改良した。ちょっと間違えると簡単に暴走するコードに機能を追加するのは大変だった。最初は、「文字列型」を追加しようと思っていたのだが、それはかなり大掛かりな仕事になると途中で気が付いたため、「文字列リテラル」のみを扱うように方向修正した。つまり、"ABCDE"と文字列リテラルを定義することは出来るが、char str="ABCDE"というように変数へ代入することは出来ないということである。まあ、スクリプト中で文字列処理するようなことは無いと思うので、問題ないはず。そもそも、NULL終端の文字列を１バイトづつ弄り繰り回さないといけないスクリプト言語なんてかなりイヤだ。おそらくスクリプト中での文字列の役割といえば、ファイル名を指定することだけだと思うので、generate("enemy.bin");というような感じで、組み込み関数へ文字列を渡せれば、それで役目は果たすだろう。とりあえず、一番ネックとなっていた部分がクリアできたので安心した。後は、スクリプトの組み込み関数を充実させれば、一通りのＳＴＧを作るためのフレームワークは最低限ではあるが、揃ったといえるだろう。

Sinテーブル

2006-03-26T22:21:00.000+09:00

Ｓｉｎテーブルを使って、Sin(x)とCos(x)を求める関数を作っていたのですが、ちょっと方針変更して、xの単位は度を使うことにしました。つまり、 Cos(360)は１になります。ラジアンを単位にするのが普通だと思いますが、スクリプト中で角度を指定するときに、ラジアンよりは度の方が感覚的に分かりやすいかと思います。

ソースコードの整理

2006-03-25T19:14:00.000+09:00

今回のスクリプトクラスとスプライトクラスの修正は結構大掛かりでした。後は大きな構造の変化を伴う修正は無いと思うので、このタイミングでコメント等も整理することにしました。前々から、コメントはDoxygenにかけるとドキュメントになる形式にするという話だったのですが、コメントをちゃんとつけながらプログラムを組むというのはなかなか面倒なもので、後回しになっていたのでした。
　ついでのついでで、関数ごとのエラーチェックの甘い部分を探して、エラー処理を強化してみたり。特にスクリプトエンジン周りは、念入りにエラーメッセージを吐き出すようにしました。スクリプトエンジン周りでエラーが発生した場合、スクリプトエンジン自体にバグがあるのか、それとも食わせているスクリプトのバグなのか、はたまたスクリプトコンパイラのバグなのか・・・と、原因の切り分けが難しくなります。#define DEBUGしている場合は、スクリプトが持っているスタックやローカルメモリにアクセスする関数で、アクセス先が適切な範囲内かチェックを行うようにしました。この場合、実行速度が犠牲になります。#define DEBUGを消せば、エラーチェック無しで全開動作するようになります。とりあえず、#define DEBUGしてあるときは、どんなめちゃくちゃなスクリプトを食わせても、アクセス違反で落ちたりすることは無くなったはずだと思います。

スプライトクラスの修正

2006-03-25T12:35:00.000+09:00

今日もスプライトクラスの設計を修正しました。スプライトクラスに寄生するように存在していた、文字列をスクリーンに描画する関数を１つのクラス（Textクラス）に独立させました。スプライトクラスを基底として、TextクラスとＢＧクラスがそれを継承する構造になりました。この効果として、スプライトコンテナにはTextでもBGでも気にせず放り込むことが出来ます。また、自分自身を描画するメソッドDraw()は、継承先でカスタマイズしてあるので、それぞれの特徴にあわせて余分な計算を省くことにより高速化できました。
　現在、ゲーム中の処理の中で一番負荷が高いのは、ＢＧの描画です。ＢＧだけでおよそ２５％ぐらいＣＰＵ時間を使用しています。これはＢＧを半透明で多重に重ね合わせて描画する処理を、マルチパスレンダリングで行っていることが重くなる原因だと思います。つまりＢＧの枚数の分だけ、何度も重ね描きをしている状態です。現在のDirect3Dでは、シングルパスで複数のテクスチャを各種の合成処理を行ってレンダリングする機能は普通にサポートされています。自分のボロノートＰＣの総合グラフィックチップの場合でも、Direct3DのDeviceのCapsを調べると、MaxSimultaneousTexturesが8なので、８枚のテクスチャを同時に処理できる様です。多分現在のグラフィックチップなら当たり前にシングルパスマルチテクスチャリングは出来るっていうことでしょう。この機能を使って、ＢＧを重ね合わせた状態で１度のパスでレンダリングすれば高速化が期待できます。今回、BGクラスは（Spriteを継承して）独立した状態になりましたので、BGクラスのDraw（）メソッドをチューンして、頂点構造体に複数のテクスチャ座標を持たせるようにすれば、少ない変更でシングルパスマルチテクスチャリングに対応可能なはずです。

スクリプトエンジンの改良４

2006-03-25T03:40:00.000+09:00

今日はスクリプトエンジンとスプライト関係に大きな修正を入れた。今までは、スクリプトオブジェクトがスプライトオブジェクトへのポインタを保持していて、スクリプトがスプライトを呼び出す形になっていた。今回の修正で、その関係が逆になり、スプライトがスクリプトを呼び出すようになった。この様に変更した理由は２つある。１つ目は、複数のスプライトで同一のスクリプトを使うという場合は良くあるが、そのときスクリプトオブジェクトのインスタンスが１つだけで済むようにするためである。２つ目は、スプライトのパラメタを直接的にスクリプトが書き換えられるようにするためである。
　スクリプトはfloat型変数６４個分の変数領域を使用できる。このうちの先頭から１８個分をスプライトのパラメタ用としてリザーブしてある。つまりスクリプトとスプライトはメモリを共有しているわけである。以前はメモリをスクリプト、スプライトがそれぞれ別にメモリ領域を持っていた為、スクリプトの実行前と実行後に、メモリの内容をお互いにコピーする必要があった。このオーバーヘッドをメモリを共有する仕組みになったことにより無くすことが出来た。この仕組みは単純な方法で実現できた。実際に使用しているコードが以下の通りである。
union
{
float mem[memSize]; //スクリプトの変数用メモリ領域
struct
{
float width; //スプライト横サイズ
float height; //スプライト縦サイズ
float x; //位置X成分
float y; //位置Y成分
float vx; //速度X成分
float vy; //速度Y成分
float ax; //加速度X成分
float ay; //加速度Y成分
float theta; //角度（θ）
float omega; //角速度(dθ/dt)
float domega; //角加速度（d^2θ/dt^2)
float animationCount; //アニメーション位置
float animationSpeed; //アニメーション速度
float animationStartCount; //アニメーション開始位置
float animationEndCount; //アニメーション終了位置
float animationInterval; //アニメーション間隔
float divideWidthNum; //テクスチャ横の分割数
float divideHeightNum; //テクスチャ縦の分割数
};
};
unionを使用して、スクリプトの変数領域と、スプライトのパラメタを同じメモリに割り当てているわけである。

BGについて

2006-03-23T23:28:00.000+09:00

BG（バックグランド）面に描画するマップチップのサイズはどの程度が適切だろうか？ファミコン等の昔のハードウェアにはPCGという機能があった。８ｘ８ドットのチップを画面に敷き詰めることが出来る機能である。今回のSTGでは、Direct３Dのテクスチャ機能をPCGに見立てたライブラリを作ろうと思う。640x480ドットのスクリーンは、昔のゲーム機から比べればずっと解像度が高いので、１つのチップが８ｘ８ドットでは細かすぎると思う。マップをエディットする手間も増えるだろう。とすれば、１６ｘ１６か、３２ｘ３２の２択になる。今回作るのは縦STGなので背景には当たり判定が無い。横STGだと背景に当たり判定のあるのが普通なので、その場合細かくマップが配置できないとまずい。しかし縦STGの背景は視覚的な要素しか持っていない為、あまり細かくする必要は無いだろう。よって、３２ｘ３２ドットのマップチップで行こうと思う。
　ゲーゼンに置いてある縦STGは縦画面になっている場合が多い。横に長すぎると、ゲームバランスが取りづらい為だと思う。ゲーセンのモニターは物理的に縦になってるが、PCのモニタはそんなことをするわけにはいかない。横６４０ドットの左右をトリミングして、縦長のレイアウトにしようと思う。
　今回のSTGでは、マップの仮想画面を５１２ｘ５１２にしようと思う。スクリーンの横６４０ドットのうち、左右それぞれ６４ドットずつをトリミングした場合、表示する部分は５１２ドットになる。スクリーンの縦は４８０ドットだが、スクロール用に画面外で見えない位置でもマップを配置しておく必要がある。そのため縦も５１２ドットとすると、マップ１行分がスクロール用として使えることになる。縦横ともに２のｎ乗の数になっているため、プログラミングする上でも楽だ。

　

スクリプトの組み込み関数を妄想する

2006-03-23T01:37:00.000+09:00

さて、STGのスクリプト言語にはどんな関数があれば、開発効率が良いでしょうか。今回のスクリプトではフレームを単位にしてスプライトの移動量などを指定します。現状だと、フレームの制御は以下のようなコードで行います。
//１０フレーム動かす
for (i = 0; i < 10; i++) end;
end命令がこのスクリプトの肝です。endを実行するたび、ゲームが１フレーム進行するわけです。スプライトは内部に速度などのパラメータを持っていますので、それらを最初に設定してやれば、あとは適当にフレームを進めることで勝手に動く設計になっています。ですがこの記述の仕方ですが、あんまりendという名前から連想される機能と、実際の機能が違っている感じがします。そういう意味ではendという名前はかなり適切ではなかったと思います。まずはこれをどうにかしたい。
frame(10);
さっきと等価なコードを上記のように書ければ、より分かりやすくなると思います。ので、frame()関数を追加したいと思います。
　STGでは、自機の位置を狙って打つ敵弾と、そうではない敵弾のバランスが重要だと思います。全ての敵弾が自機の位置に正確に狙って打たれた場合、自機を小刻みにちょっとずらすだけで簡単に避けられてしまいます。逆に全ての敵弾がランダムな方向に打たれた場合は、場合によっては自機をまったく動かさなくても敵弾を避けられてしまう場合も出てくるでしょうし、逆に自機をあまり動かしすぎると流れ玉に当たって理不尽な死に方をする羽目になると思います。自機の位置を狙って打つ敵弾と、そうではない敵弾では、避け方が違ってくるということです。この２つをうまく混ぜることによって、プレイして面白いSTGになるのではないかと思います。
　というわけで、自機の方向にキャラクタの角度を向ける関数が必要ですね。LookAtPlayer()なんていう名前の関数にしようと思います。
　もっと肝心な関数があります。弾などを発射するための関数です。スプライトのシステムから見た場合、敵キャラクタ、プレイヤーのキャラクタ、敵弾及び自機から発射された弾、これらは区別がありません。これらは全てGenerate()関数を使って生成するようにしようと思います。Generate("enemy1.bin");のような感じで、新しいキャラクタを生成します。enemy1.binはそのキャラクタを制御するスクリプト（のバイナリ）名です。
　STGといえば、多間接は外せない要素でしょう。多間接の物体をどうやって定義するかが問題となります。そこでChild()関数というのを入れようと思います。Child("enemy1.bin");という感じで使います。この場合、enemy1.binというスクリプトで新しい子のキャラクタを作るわけです。基本的にはgenerate()とあまり変わらないのですが、childの場合、子となるキャラクタの座標系は、子を生成した親キャラクタの位置を中心としたローカルな座標系となります。つまり、親が動けば、子も一緒に動くようになるわけです。逆に子が動いても、親の位置は変化しません。たぶん、この機能があれば簡単に多間接を実現できるはずです。

コンソールはUNICODE非対応なの？

2006-03-22T23:42:00.000+09:00

このSTGは一応UNICODE用ってことで開発していたのですが、実はコンソールに文字を出力する部分などはShift-JISのままになっていたのです。何故かといえば、コンソールに文字を出力してもUNICODEだと文字化けするからです。たとえば、
int _tmain(int argc, _TCHAR* argv[]) {
wprintf(L"テスト\n");
return 0;
}
みたいなコードを実行してもコンソールには何も表示されませんでした。コンソールのプロパティーを見ると「現在のコードページ」っていうのがShift-JISになっている。これじゃ明らかに駄目っぽい。そこで「コンソール　UNICODE」でググると、それの対処法がたくさん出てきました。
setlocale(LC_CTYPE, "japanese");
という一行を、文字を出力する前に入れておけばよかっただけの事でした。もっと早く調べておけばよかった。

キャラクタのコンテナクラスの作成

2006-03-22T23:14:00.000+09:00

STGのキャラクタは、自機の弾に当たって爆発・消滅する、画面外に出る、マップのスクロールにしたがって発生する、等の要因で生成と消滅を何度も繰り返す。キャラクタを格納しておくデータ構造は、要素の追加、削除が高速に行えるものでないと、STGの様なゲームでは問題になるだろう。その要求を満たすデータ構造といえば、STLのlistでもいいのだが、listはランダムアクセスが出来ないデータ構造である。配列のようにランダムアクセスが出来たほうがプログラムを組む上で、簡単になって良い。そんなことから、昔、弾幕系STGの弾を格納するのに都合が良いクラスを作成したことがある。
　そんなわけで、昔使ったコードを引っ張り出してきて今回のSTGに追加してみた。多少手直しは必要だった。クラスの名前も意味が分からないものが付いていたので、ObjectPoolという名前に付け直した。このクラスは、ちょっと使用に注意が必要な部分があるが、生の配列を直接使うのとなんら変わらない速度が出るはずだ。
　

スクリプトインタプリタの負荷について

2006-03-21T22:24:00.000+09:00

１つのスプライト（敵キャラ等）に１つのスクリプトを割り当てるようにしたため、スプライトを最大で２５６個発生させる場合、スクリプトも２５６個並列に実行する必要がある。スクリプト実行はどの程度の負荷になるか想像が出来なかったので実際に実験してみた。とりあえず、２５６個のスクリプトを並列実行してみたところ、CPU負荷は１％～３％をうろうろしている感じであった。この２５６という数字は、怒首領蜂のスプライトリミットが２５６個らしいということに起因している。怒首領蜂がスプライト数２５６個で何とかなってるならば、たぶんそれぐらいのスプライトを動かせれば弾幕STGを作るうえで十分だろうという判断である。スクリプトの記述内容がかなり単純な事もあるが、実行速度は十分出ているようである。スクリプトの記述が複雑になった場合はどうなるかは分からない。
　今はやっつけ仕事でスクリプトインタプリタを実装したため、無駄な部分も多い。スプライトオブジェクトとスクリプトオブジェクトは、それぞれどちらも内部にキャラクタの座標、速度、角度などのパラメタを持っている。そのパラメタはfloat型やint型で１７個ほどである。現状だと、スクリプトを実行した結果、変化したパラメタをスプライトに反映するために、毎回これらのパラメタをスクリプト側からスプライト側へコピーしている。これは無駄であるので、スクリプトとスプライトのパラメタは共通にしてコピーのオーバーヘッドを無くしたいと思う。

スクリプトエンジンの改良３

2006-03-21T18:26:00.000+09:00

さっきから、スクリプトコンパイラのソースコードの修正を試みていたんだが、昔のコードだし細かい所はまったく覚えていない上にコメントがほとんどなく、ポインタ使いまくり（再帰下降でパースしていく仕組みだから、まあそういうものかもしれないが）なので、修正はかなり難しそうである。コーディングの仕方自体も、ファイル内スコープとなるstaticで宣言した変数を使って、それをメンバ変数に見立ててカプセル化を行っていたりして、かなり怪しげな組み方である。C++でStringとSTLを使って組みなおしたい衝動に駆られるが、そんなことをしていたらいつになったらSTGが完成するかわかったもんじゃない。
　スクリプトの言語仕様に一番加えなければならない機能は、組み込み関数の呼び出しだろう。スクリプト内で、関数を定義する必要はほとんど無いと思われるので、組み込み関数を呼び出せれば十分である。組み込み関数ってのは、言語処理系が最初から用意している関数の事である。BASICだとABSとかMID$とかPUT@とかあらかじめ関数が用意されている。こういうのは全部組み込み関数にあたる。C言語などと違って、古典的なBASIC言語は関数を自分で作ることは出来ないのが大きな違いだと思う。今回はBASICみたいに、関数定義が出来なくても、呼び出しが出来ればいい。
　この場合、スクリプトコンパイラがやらなければならない仕事は、関数名と引数の数をチェックを行ってから、引数の数を最初にスタックに積んで、その後に引数をスタックに積んでいく、というようなコードを生成することになるだろう。めんどくせー。

スクリプトエンジンの改良２

2006-03-21T14:24:00.000+09:00

下で、「拡張子を除き、スクリプトのファイル名と同じファイル名の画像をロードする」という仕様にする、ということ書いたが、ちょっと考えてみるとそれには問題が多いことに気が付く。Direct３Dのテクスチャは、横と縦のサイズが２５６テクセルの正方形の場合に最良のパフォーマンスが出るように最適化してあるらしい（DirectX９のSDKドキュメントにそのような記述がある）。STGの普通のザコ敵キャラは大体３２×３２ドット程度のサイズで用意するのが普通だと思う。テクスチャのサイズが２５６×２５６ならば、その中に３２×３２ドットのキャラクタは６４個入るわけだ。つまり、１つのテクスチャファイルに複数のキャラクタ画像を入れた方が効率が良い。そうすると、１つのテクスチャファイルを複数のスクリプトから参照して使う必要が出てくる。しかし、前述の「拡張子を除き、スクリプトのファイル名と同じファイル名の画像をロードする」という仕様の場合、スクリプトとテクスチャが１対１で対応する関係しか指定できないので、問題になるわけだ。さてどうすっかなあ。

スクリプトエンジンの改良

2006-03-21T13:38:00.000+09:00

最終的には、スクリプト（とマップエディタ）だけをいじれば、ゲームの進行は全て制御できるようにしたい。しかし、現状ではスクリプトの機能が不足していて、C++側で書かなければならない部分が多い。１つの種類の敵キャラクタに対して、１つのファイルのスクリプトを割り当てて記述するようにしたいので、テクスチャの指定などもスクリプト側で行うようにしたい。しかし、今のスクリプトは文字列が扱えない（文字列を扱う型が無い）ので、テクスチャのファイルを指定することができない。確か、lexerとparserは文字列リテラルをちゃんと識別するように作ってあったはずだが、semantec analysysの段階では変数の型というものをdouble型しか用意してなかったものだから、文字列などは捨てる設計になってしまっていた記憶がある。これを改良するには、３年前に作ったコードの深い部分を改変することになるので、ちょっと大変そうだ。
　スクリプトコンパイラはたぶんバグも結構抱えている古いコードなのであんまり弄くり回す気にはなれない。仕方ないので、テクスチャファイルの指定は、「拡張子を除き、スクリプトのファイル名と同じファイル名の画像をロードする」という仕様にするかもしれない。たとえば、スクリプトをコンパイルして出来上がったバイナリが、"enemy1.bin"という名前だった場合、自動的に"enemy1.png"というファイルをテクスチャとしてロードするようにするわけだ。これなら、スクリプトコンパイラには手をつけずに目的を達成できるはず。

スクリプトエンジン組み込み

2006-03-21T00:18:00.000+09:00

とりあえず、スクリプトコンパイラは出来ているものをそのまま使うことにして、スクリプトインタプリタだけをSTG用にアレンジして組み込んでみました。スクリプトの言語仕様は、かなりC言語に似せてあるのでスクリプトを使わずに組む場合とあんまり効率が変わって無いような気がしますが、とりあえず言語仕様をチューンするのは置いておいて、まずは動かすことを優先することにしました。
　元となったスクリプトインタプリタのコードは、3年ぐらい前に組んだもので、Pure ANSI Cになるように意識して組んだ記憶があります。つまり、C++の機能を使わずに組んであるということであります。なんでこんなことをしたかと言うと、最終的には作成したコンパイラで、そのコンパイラをコンパイルしてやろうと考えていたからであります（コンパイラに自分自身をコンパイルさせるって事です）。
　と言うわけで、C++の機能を使わずに素朴に組んであったスクリプトインタプリタのコードを、今回は現代風にC++でOOP風に書き換えました。これによって、スクリプトインタプリタオブジェクトのインスタンスを必要な数だけ作ってやれば、複数のスクリプトを同時実行できるようになりました。

Releaseビルドのバイナリが落ちる件について

2006-03-20T23:10:00.000+09:00

一旦、VC++のプロジェクトファイルを削除して、もう一回プロジェクトを新規作成してから、コンパイルとリンクのオプションを慎重に設定し直しました。そうしたら、Releaseビルドのバイナリを実行しても落ちなくなりました。今までのは何だったんだろう・・・
　ついでに、インクルードファイルやライブラリのディレクトリの設定を、NPK氏の環境に合わせて設定しておいた。これで、ソースコード一式を送りつけても、簡単にビルドしなおせるようになると思う。

スクリプトエンジン作成

2006-03-20T22:46:00.000+09:00

ゲームの敵キャラクタの動き（敵のアルゴリズム）等は、実際にゲームを動かしながら、試行錯誤で調整していく必要があります。試行錯誤が必要となる部分は、ゲーム本体のコードとは別にしたほうが、開発効率の面で有利になるはずです。パラメータをちょっと変えるたびに、メインのC++コードを毎回コンパイルし直すのは大変です。
　今回、開発するSTGでは、敵などのアルゴリズムを記述するために専用のスクリプト言語を用意します。スクリプト言語を記述することにより、C++コードをコンパイルし直すこと無く、ゲームの進行を変えることができます。また、STGに特化した言語仕様でスクリプトエンジンを作ることによって、敵アルゴリズムなどを記述する事については、C++よりも小回りが効いて組みやすくなることを狙っています。
　しかし、スクリプト言語を１から作るのは結構大変です。今回は、3年ぐらい前に作ったまま放置してあった、スクリプトコンパイラやインタプリタなどを引っ張りだしてきて、STGに組み込んでみることにしました。さてうまくいくかな・・・

SoundLib組み込み

2006-03-20T01:31:00.000+09:00

私はSTGのプログラムの中でも、今はグラフィック周りのプログラムを担当しています。
NPK氏が作成した、oggをデコードしつつDirectSoundで再生するライブラリ「SoundLib」と、私が作っていたプログラムを組み合わせました。私はASCII、NPK氏はUNICODEで開発していたので、どっちかにあわせないとコンパイルエラーがでまくります。今回は全部をUNICODEで統一することにしました。なんとか、今まで作っていた部分をUNICODE用に書き換え、SoundLibを組み込みました。しかし、Debugビルドで作成したバイナリを実行した場合、うまく動くのですが、Releaseビルドの場合は途中で落ちてしまう模様。

このBlogについて

2006-03-19T18:12:00.000+09:00

どうも、polygonizeです。

　私は、サークル「Troubadour」で開発中のSTG、「Metal Breaker」のプログラム製作を担当しております。このBlogでは、そのプログラム製作の進捗状況を記録していこうと思います。Blogという形で、プログラム制作上で発生した問題点と改善策を明文化していくことで、サークルメンバーの間での情報共有が容易になればいいなと思います。