--- a/paper/game.tex	Fri Feb 04 19:38:35 2011 +0900
+++ b/paper/game.tex	Sat Feb 05 18:21:47 2011 +0900
@@ -61,4 +61,3 @@
 ランダム性は、テストをする上でバグの再現を困難にする。この問題に対して、
 常に同じ乱数列を生成するように、乱数生成器を無効にするか、定数でシードする
 といった手法が考えられる。
-

--- a/paper/images/dandy.bb	Fri Feb 04 19:38:35 2011 +0900
+++ b/paper/images/dandy.bb	Sat Feb 05 18:21:47 2011 +0900
@@ -1,5 +1,5 @@
 %%Title: ./images/dandy.pdf
 %%Creator: extractbb 20100328
-%%BoundingBox: 0 0 1115 645
-%%CreationDate: Tue Feb  1 14:46:13 2011
+%%BoundingBox: 0 0 1105 660
+%%CreationDate: Fri Feb  4 19:41:00 2011
 

Binary file paper/images/dandy.pdf has changed

--- a/paper/test.tex	Fri Feb 04 19:38:35 2011 +0900
+++ b/paper/test.tex	Sat Feb 05 18:21:47 2011 +0900
@@ -1,6 +1,125 @@
 \chapter{テスト環境の構築} \label{chapter:test}
-ここでは本研究の為に実装した機能とテストの実行環境、
+本研究では、逐次型プログラムとして Super Dandy の OpenGL バージョン、Cerium 
+の Rendering Engine のみを使用したバージョンを用意した。これらと Task Dandy 
+を用いてその挙動をテストし、全てのバージョンにおいて全く同じ動作となる事を
+目指した。ここではテストを進める過程で追加した機能とテスト環境について
+説明する。
 
 \section{Capture モードと Trace モード}
+ゲームにおいてプレイヤーからの入力は制御不能なランダム要素であり、
+バグを再現することを困難にする(\ref{sec:player}節)。
+そこでプレイヤーからの入力を1フレーム毎に記録し、バイナリデータとして
+書き出す Capture モードと書き出されたバイナリデータを読み込み、プレイヤーの
+入力を再現する Trace モードを実装した。どちらのモードも実行ファイルに
+オプションとファイル名を付けることによって起動することが出来る。
+
+\begin{verbatim}
+% ./demo -capture capture.dat
+Start Capture mode.
+
+% ./demo -trace capture.dat
+Start Trace mode.
+\end{verbatim}
+
+2 つのモードでは TraceBuff という単方向リスト型のバッファを使用している。
+Capture モードではバッファサイズが足りなくなると新たな TraceBuff を allocate 
+して next ポインタにアドレスを格納する。バイナリデータに書き出す時はリストの
+先頭から順番に書き出していく。
+
+Trace モードではバイナリデータのサイズを計算し、予め必要なサイズの TraceBuff
+を allocate しておく。
+(図\ref{fig:pad_buff})
+
+\begin{figure}[h]
+\begin{center}
+\includegraphics[scale=0.8]{images/pad_buff.pdf}
+\end{center}
+\caption{TraceBuff}
+\label{fig:pad_buff}
+\end{figure}
+
+この 2 つのモードは用意された 3 つの Super Dandy 全てに組み込まれている。
+よって旧バージョンで入力データを記録し、記録したデータを新バージョンで
+読み込むことも可能である。これにより、両バージョンで異なる動きが見られた
+場合、そこにバグが潜んでいると仮定することができる。
+
 \section{乱数生成}
-\section{テストログのためのデータ構造}
+乱数のランダム性はバグの再現性を落とすが、乱数生成器を無効にするか、定数で
+シードすることによって再現性を下げることなく、テストすることが出来る
+(\ref{sec:random}節)。
+
+
+\section{テストログとそのタイミング}
+シーケンシャルなプログラムを Task に分割して並列実行する際に、新たに発生する
+バグとして、本研究では以下の項目に焦点を当てた。(図\ref{fig:test_log})
+
+\begin{itemize}
+\item Task 間のデータの同期
+\item Task の実行順序
+\item Task の定義
+\end{itemize}
+
+\begin{figure}[h]
+\begin{center}
+\includegraphics[scale=0.8]{images/test_log.pdf}
+\end{center}
+\caption{Task Dandy で起こりうるバグ}
+\label{fig:test_log}
+\end{figure}
+
+このうち、Task の定義については、定義される内容が非常に小さい為、Task の
+inData や outData を調べるといった従来の単体テストでも十分にテストが可能で
+ある。その他の 2 つについては、いずれも衝突判定の際に生じるバグである。
+
+そこで、オブジェクトが被弾した時、そしてオブジェクトが生成された時にテスト
+ログを取ることで効率的にバグを発見することができると考えた。以下に実際に
+収集したテストログの例を示す。
+
+\begin{verbatim}
+F64: CREATE  [NAME]enemy_greenclab_0  [COORD]x= 120.000000  y= -128.000000  vx= 0.000000  vy= 4.000000
+F85: DELETE  [NAME]enemy_greenclab_0  [COORD]x= 120.000000  y= -44.000000  vx= 0.000000  vy= 4.000000
+             [TAMA]lv1 = 2, lv2 = 0 [LASER]lv1 = 0
+\end{verbatim}
+
+それぞれのパラメータの詳細は次のとおりである。
+
+\begin{itemize}
+\item F64,F85\\
+  生成、もしくは被弾した時の経過フレーム。
+\item CREATE,DELETE\\
+  CREATE ならオブジェクトが生成された、DELETE ならオブジェクトが被弾した事を
+  表す。
+\item [NAME]\\
+\item [COORD]\\
+  オブジェクトが存在した座標とその時の速さの x 成分、y 成分。
+\item [TAMA],[laser]\\
+  被弾した際の、画面上に生成されているプレイヤーの弾丸オブジェクトの数を
+  表している。
+\end{itemize}
+
+これにより、フレーム単位でどのオブジェクトが生成、または被弾したのか知ること
+ができる。trace モードでプレイヤーの入力を固定し、各バージョンでテストログを
+取り、その差異を調べることでバグが発生している時間や場所を特定することが
+できる。
+
+\section{描画処理を行わないビデオモード}\label{sec:video_none}
+Cerium では Rendering Engine において 3 つの Task を用いて画面の描画処理を
+行っている(\ref{sec:rendering}節)。Cerium では複数の環境で動作するように
+オブジェクトを画面のフレームバッファに直接書き出すモードや、SDL のバッファに
+書き出すモードなど、複数のビデオモードが存在する。しかし、プレイヤーの入力を
+バイナリデータに書き出し、読み出す場合、画面の描画処理は不要となる。
+
+そこでテスト用に画面の描画処理を行わないモードを Cerium に実装した。
+これは、Cerium 内で画面のバッファを確保する処理をしている箇所と、描画用の 
+Task を生成する処理をしている箇所をスルーすることで描画処理と無駄なメモリ
+確保を行わないビデオモードである。(図\ref{fig:video_none})
+
+\if0
+\begin{figure}[h]
+\begin{center}
+\includegraphics[scale=0.8]{images/video_none.pdf}
+\end{center}
+\caption{描画処理を行わないビデオモード}
+\label{fig:vodeo_none}
+\end{figure}
+\fi