--- a/paper/implement.tex	Sat Feb 05 18:21:47 2011 +0900
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,6 +0,0 @@
-\chapter{Task を用いたパイプラインの実装} \label{chapter:implement}
-
-\section{Task}
-\section{Scheduler}
-\section{評価}
-

--- a/paper/test.tex	Sat Feb 05 18:21:47 2011 +0900
+++ b/paper/test.tex	Sun Feb 06 01:56:30 2011 +0900
@@ -48,6 +48,54 @@
 シードすることによって再現性を下げることなく、テストすることが出来る
 (\ref{sec:random}節)。
 
+通常のシーケンシャルなプログラムでは 1 つの乱数列から順番に各 Move 関数が
+乱数を取得し、使用する。しかし並列プログラムでは Move 関数が Task として 
+SPE に送られる。各 SPE 内では以下のような処理が行われる。
+
+\begin{enumerate}
+\item 定数でシードし、乱数列を生成する。
+\item Task1 で乱数列の先頭から 1 番目の乱数を取得する
+\item Task2 で乱数列の先頭から 2 番目の乱数を取得する
+\item Task3 で乱数列の先頭から 3 番目の乱数を取得する
+\end{enumerate}
+
+乱数列は SPE 毎に独自に生成されるため、各 Task(=Move) が受け取る乱数は
+逐次実行した時とは異なる値となってしまう。また、SPE 内でも Task 同士に
+依存関係を持たせない限り、Task の実行順序が保証されないのでこれも受け取る
+乱数が不定となる原因となる。(図\ref{fig:spe_random})
+
+そこで予め PPE 内で乱数列を生成し、inData として Task に渡しておく。
+Task Dandy では Task の生成、定義がされるタイミングは Super Dandy における
+Move 関数や Collision 関数が実行されるタイミングと同じである為、渡される乱数
+は Super Dandy と同じ乱数となる。(図\ref{fig:ppe_random})
+
+\newpage
+
+\begin{figure}[h]
+\begin{center}
+\includegraphics[scale=0.5]{images/spe_random.pdf}
+\end{center}
+\caption{SPE 内での乱数の生成}
+\label{fig:spe_random}
+\end{figure}
+
+\begin{figure}[h]
+\begin{center}
+\includegraphics[scale=0.5]{images/ppe_random.pdf}
+\end{center}
+\caption{PPE 内での乱数の生成と乱数の受け渡し}
+\label{fig:ppe_random}
+\end{figure}
+
+\newpage
+
+\begin{figure}[h]
+\begin{center}
+\includegraphics[scale=0.8]{images/test_log.pdf}
+\end{center}
+\caption{Task Dandy で起こりうるバグ}
+\label{fig:test_log}
+\end{figure}
 
 \section{テストログとそのタイミング}
 シーケンシャルなプログラムを Task に分割して並列実行する際に、新たに発生する
@@ -59,14 +107,6 @@
 \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 つについては、いずれも衝突判定の際に生じるバグである。
@@ -76,8 +116,10 @@
 収集したテストログの例を示す。
 
 \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
+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}
 
@@ -89,12 +131,14 @@
 \item CREATE,DELETE\\
   CREATE ならオブジェクトが生成された、DELETE ならオブジェクトが被弾した事を
   表す。
-\item [NAME]\\
-\item [COORD]\\
-  オブジェクトが存在した座標とその時の速さの x 成分、y 成分。
-\item [TAMA],[laser]\\
-  被弾した際の、画面上に生成されているプレイヤーの弾丸オブジェクトの数を
-  表している。
+\item NAME\\
+  オブジェクトの種類と ID。ID はオブジェクトの種類毎に 0 から順番に付けられ
+  るのでどのオブジェクトの情報なのかを特定できる。
+\item COORD\\
+  オブジェクトのxy座標とxy方向の速度。
+\item TAMA,LASER
+  その瞬間に画面内に存在した弾の数。差異があれば同期が取れていないことを
+  示す。
 \end{itemize}
 
 これにより、フレーム単位でどのオブジェクトが生成、または被弾したのか知ること
@@ -106,15 +150,24 @@
 Cerium では Rendering Engine において 3 つの Task を用いて画面の描画処理を
 行っている(\ref{sec:rendering}節)。Cerium では複数の環境で動作するように
 オブジェクトを画面のフレームバッファに直接書き出すモードや、SDL のバッファに
-書き出すモードなど、複数のビデオモードが存在する。しかし、プレイヤーの入力を
-バイナリデータに書き出し、読み出す場合、画面の描画処理は不要となる。
+書き出すモードなど、複数のビデオモードが存在する。
+(図\ref{fig:video_mode})
 
+しかし、プレイヤーの入力をバイナリデータから読み出す場合、処理の詳細が
+知りたい場合を除いて画面の描画処理は不要となる。
 そこでテスト用に画面の描画処理を行わないモードを Cerium に実装した。
 これは、Cerium 内で画面のバッファを確保する処理をしている箇所と、描画用の 
 Task を生成する処理をしている箇所をスルーすることで描画処理と無駄なメモリ
 確保を行わないビデオモードである。(図\ref{fig:video_none})
 
-\if0
+\begin{figure}[h]
+\begin{center}
+\includegraphics[scale=0.6]{images/video.pdf}
+\end{center}
+\caption{通常のビデオモード}
+\label{fig:video_mode}
+\end{figure}
+
 \begin{figure}[h]
 \begin{center}
 \includegraphics[scale=0.8]{images/video_none.pdf}
@@ -122,4 +175,3 @@
 \caption{描画処理を行わないビデオモード}
 \label{fig:vodeo_none}
 \end{figure}
-\fi