--- a/poster/master-lt.html	Thu Feb 17 14:49:08 2011 +0900
+++ b/poster/master-lt.html	Fri Feb 18 05:39:37 2011 +0900
@@ -60,29 +60,24 @@
 <li>本研究では Task に分割されたゲームプログラムがシーケンシャルなバージョン
 と同じ動作である事を確認できるテスト環境の構築を目的とする。</li>
 </ul></font>
-<center>
-<img src="images/cell.png" width=350 height=150/>
-</center>
 </div>
 
 <div class="slide">
-<h1>ゲームプログラムの特徴</h1>
-<ul class="simple">
-  <li>遷移する状態が膨大</li>
-  <li>実際にプレイヤーがゲームをプレイするのが重要なテスト</li>
-  <li>プレイヤーの入力は常に非決定的(毎回結果が異なる)</li>
-  <li>乱数のランダム性がデバッグをする上でバグの再現を困難にする</li>
-</ul>
-</div>
-
-<div class="slide">
-<h1>Capture モードと Trace モード</h1>
-<ul class="simple">
-  <li>プレイヤーからの入力を 1 フレーム毎に記録して書き出す</li>
-  <li>書き出したファイルを読み込むことで過去のプレイヤー入力を再現できる</li>
-  <li>旧バージョンの入力を記録し、新バージョンで読み出すことができる</li>
-  <li>入力が同じでも動作が違えばそこにバグが潜んでいると考えられる</li>
-</ul>
+<h1>並列処理をすることによって発生するバグ</h1>
+<table>
+  <tr>
+    <td><ul>
+	<li>Task の実行順序の違いによりバグが発生</li>
+	<li>Task 間のデータの同期による衝突判定のバグ</li>
+	<li>Task の実装の違い</li>
+	<li>オブジェクトの生成時、衝突時にゲームの状態が遷移する</li>
+	<li>オブジェクトの生成時、衝突時のログを見ることでバグを発見する</li>
+    </ul></td>
+    <td>
+      <img src="images/test_log.png" width=350 height=300/>
+    </td>
+  </tr>
+</table>
 </div>
 
 <div class="slide">
@@ -90,76 +85,26 @@
 <table>
   <tr>
     <td><ul class="simple">
-	<li>あらかじめ PPE 内で乱数列を生成しておく</li>
-	<li>inData として Task に渡す</li>
-	<li>Move Task や Collision Task の生成タイミングは Super Dandy の
-	Move や Collision のタイミングと同じ</li>
-	<li>Super Dandy と同じ乱数が使用できる</li>
+	<li>シーケンシャルプログラムでは 1 つの乱数列から順番に乱数を取得</li>
+	<li>Cell における並列プログラムでは各 SPE 内で 独自の乱数列を生成</li>
+	<li>シーケンシャルと並列で異なる結果が出る</li>
+	<li>PPE 内で乱数を生成し、Task に渡して計算させる</li>
+	<li>シーケンシャルと同じ乱数が使用できる</li>
     </ul></td>
     <td>
-      <img src="images/ppe_random.png" width=400 height=300/>
-    </td>
-  </tr>
-</table>
-</div>
-
-<div class="slide">
-<h1>本研究のテスト環境における描画処理</h1>
-<table>
-  <tr>
-    <td><ul class="simple">
-	<li>プレイヤーの入力の自動化により、プログラムを実行するだけでテストが可能</li>
-	<li>描画処理が不要となる</li>
-	<li>描画用 Task の生成を行わない事により、テストの高速化ができる</li>
-	<li>また、画面バッファの確保も不要</li>
-    </ul></td>
-    <td>
-      <img src="images/video2.png" width=300 height=300/>
+      <img src="images/cell.png" width=300 height=200/>
     </td>
   </tr>
 </table>
 </div>
 
 <div class="slide">
-<h1>シューティングゲーム SuperDandy</h1>
-<table>
-  <tr>
-    <td><ul class="simple">
-	<li>我々が PlayStation 上でのゲーム開発を行っていた 1998 年に開発</li>
-	<li>タイトルからゲーム本編中の敵機の登場、ステージクリア、エンディングと
-	  ゲーム的な要素が多い</li>
-	<li>PlayStation, PlayStation2 Linux, OpenGL と伝統的に移植されてきた</li>
-    </ul></td>
-    <td>
-      <img src="images/dandy.png" width=300 height=250/>
-    </td>
-  </tr>
-</table>
-</div>
-
-<div class="slide">
-<h1>Task への乱数受け渡しと検証結果</h1>
+<h1>Capture モードと Trace モード</h1>
 <ul class="simple">
-  <li>多数の隕石オブジェクトが生成されるステージで全ての隕石オブジェクトが
-  生成されるのを観察</li>
-  <li>隕石オブジェクトの初期配置は乱数によるランダム配置</li>
-  <li>隕石オブジェクト生成後の座標と速度を出力</li>
-  <br>
-  <li>生成された隕石オブジェクトのパラメータが両バージョンで一致している</li>
-  <li>Task への乱数受け渡しによるバグの再現性の低下防止は有効である</li>
-</ul>
-</div>
-
-<div class="slide">
-<h1>実行結果</h1>
-<table border="1" cellspacing="0">
-  <tr><td></td><th>OpenGL</th><th>Task(no video)</th><th>Task</th></tr>
-  <tr><th>実行時間</th><td>336.09 sec</td><td>385.17 sec</td><td>6643.16 sec</td></tr>
-</table>
-<ul class="simple">
-  <li>Task バージョンは劇的に処理時間が増加</li>
-  <li>描画処理の Task の処理時間が非常に大きいと考えられる</li>
-  <li>描画処理の Task に比べればゲームの Task は処理が小さい</li>
+  <li>プレイヤーからの入力を 1 フレーム毎に記録する</li>
+  <li>記録したファイルを読み込むことで過去のプレイヤー入力を再現できる</li>
+  <li>旧バージョンの入力を記録し、新バージョンで読み出すことができる</li>
+  <li>非決定的なプレイヤー入力を固定することができる</li>
 </ul>
 </div>
 
@@ -167,12 +112,12 @@
 <h1>結論</h1>
 <h2>本研究では並列環境におけるゲームプログラムのテスト手法を提案した</h2>
 <ul class="simple">
-  <li>衝突判定時のテストログ出力によるデバッグは OpenGL バージョンと Task 
-    Dandy の実行結果が同じであることから、効果的であった</li>
-  <li>Task への乱数受け渡しによるバグの再現性は 同様にして有効であることが
-    わかった</li>
-  <li>描画をしないビデオモードによるテスト時間の高速化は、描画をする場合に
-  比べて 非常に効果があった</li>
+  <li>衝突判定時のテストログ出力によるデバッグは OpenGL と Task Dandy の
+    実行結果が同じであることから、効果的であった</li>
+  <li>Task への乱数受け渡しによって逐次実行、並列実行で使用する乱数を
+  同じものにした</li>
+  <li>入力の自動化により、描画を行わずにテストを行ったところ、
+    テスト時間を短縮することが出来た</li>
 </ul>
 </div>