Mercurial > hg > Papers > 2011 > koba-sigss

changeset 9:b7b8c6307895 default tip

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
finish.
author koba <koba@cr.ie.u-ryukyu.ac.jp>
date Tue, 08 Mar 2011 19:17:46 +0900
parents 7e707cabd73a
children
files presen/graffle/collision_uml.graffle presen/images/collision_uml.png presen/sigss-presen.html
diffstat 3 files changed, 231 insertions(+), 215 deletions(-) [+]
line wrap: on
line diff
Binary file presen/graffle/collision_uml.graffle has changed
Binary file presen/images/collision_uml.png has changed
--- a/presen/sigss-presen.html	Mon Mar 07 00:38:23 2011 +0900
+++ b/presen/sigss-presen.html	Tue Mar 08 19:17:46 2011 +0900
@@ -30,7 +30,7 @@
 <div id="header"></div>
 <div id="footer">
 <h1>[date:11/03/08]</h1>
-<h2>Game Framework Cerium を用いたゲームプログラミングにおけるテスト手法の提案</h2>
+<h2>GameFrameWork Cerium におけるSequential な Game Program の分割と動作の検証</h2>
 </div>
 
 </div>
@@ -66,19 +66,15 @@
 <div class="slide">
 <h1>研究要旨</h1>
 <font size="3"><ul>
-<li>我々は PlayStation3(以下 PS3) のマルチコアアーキテクチャ Cell B.E を用いて
-  並列処理を行うゲームフレームワーク Cerium を開発した。Cerium では
-  プログラムを Task という単位に分け、Cell B.E に渡して並列処理を行う。</li>
-<li>シーケンシャルなプログラムを Task に分割して並列実行させても、
-  データの同期や実行順序の違いなどにより逐次実行させた時と同じ動作をするとは
-  限らない。また、ゲームプログラムにはプレイヤーの入力や乱数などの非決定的な
-  要素が多く、バグの再現性が低い。</li>
+<li>当研究室のPlayStation3用マルチコア並列ゲームフレームワーク Cerium ではプログラムをTaskという単位に分割して並列処理を行う。
+<li>Ceriumに既存の逐次型のゲームを移植すると、Taskの並列実行による非決定的な実行により、同じ動作にならない場合がある。
+<li>ゲームプログラムにはプレイヤーの入力や乱数などの非決定的要素が元々入っており、単純な動作比較ではうまくいかない。
 <br>
-<li>本研究ではシーケンシャルなゲームプログラムを逐次実行した時と Task に分割
-  した時の動作が同一である事を確認できるテスト環境を構築する。
-  ゲームプログラムにおける非決定的な要素を固定化し、ゲームの状態遷移時に
-  おいてバグの検出を行うことで並列実行時のバグを発見する。</li>
-<li>ゲームの状態数を数え上げ</li>
+<li>本研究ではプログラムの実行ログを取得し移植時の動作の比較を行う。
+<li>そのために入力と乱数による非決定的な要素の固定化を行った。
+<li>並列実行はCeriumのFifo実行機能を用いて決定的な動作を実現した。
+<br>
+<li>Super Dandyというシューティングゲームに本方法を適用し実用的な時間内での動作比較を行うことができた。
 </ul></font>
 </div>
 
@@ -96,22 +92,19 @@
     繋がっている</li>
 </ul>
 </div>
--->
 
 <div class="slide">
 <h1>Game Framework Cerium</h1>
-<h2>オブジェクトの管理や描画、Task の管理を行う</h2>
-<dl>
-  <b><dt>SceneGraph</dt></b>
-  <dd>オブジェクトのパラメータやポリゴン情報を tree 構造のノードで管理</dd>
-  <b><dt>Rendering Engine</dt></b>
-  <dd>3 種類の Task によって並列に描画処理を行う</dd>
-  <b><dt>TaskManager</dt></b>
-  <dd>Task を動的に SPE へ割り振るカーネルとして振舞う</dd>
-</dl>
+<h2>プログラムを Task と呼ばれる分割された単位で管理する</h2>
+<ul>
+<li>Task の単位はサブルーチンまたは関数とする</li>
+<li>Task には依存関係や処理させる CPU などを設定することができる</li>
+<li>生成された Task を依存関係を考慮しながら Cell B.E に送る</li>
+</ul>
+<br>
+<h2>独自の RenderingEngine により、Task を用いた描画処理を行うことが出来る</h2>
 </div>
 
-<!--
 <div class="slide">
 <h1>Game Framework Cerium</h1>
 <dl>
@@ -123,9 +116,7 @@
   <dd>Task を動的に SPE へ割り振るカーネルとして振舞う</dd>
 </dl>
 </div>
--->
 
-<!--
 <div class="slide">
 <h1>Task に設定できる項目</h1>
 <ul class="simple">
@@ -160,9 +151,7 @@
 <li>一般的な単体テストではゲームのバグの発見は難しい</li>
 </ul>
 </div>
--->
 
-<!--
 <div class="slide">
 <h1>ゲームプログラムの特徴</h1>
 <ul class="simple">
@@ -193,24 +182,46 @@
 -->
 
 <div class="slide">
+<h1>シューティングゲーム Super Dandy</h1>
+<table>
+  <tr>
+    <td>
+    <font size="4"><ul class="simple">
+	<li>PS2上の全5 ステージのボリュームのあるシューティングゲーム
+	<li>PS3上に移植する際にTask分割して並列実行を行うようにする
+	<li>ゲームオブジェクトはSceneGraph上に以下のState Patternを用いて構築されている
+	<li>State Pattern一つ一つをTaskとして実装する
+        <ul>
+	    <li>オブジェクトの移動(Move)
+	    <li>衝突判定(Collision)
+	    <li>ステージ毎のオブジェクト生成(Schedule)
+        </ul>
+    </ul></font>
+    <td>
+      <img src="images/dandy.png" width=300 height=250/>
+</table>
+</div>
+
+<div class="slide">
 <h1>ゲームプログラムの特徴</h1>
 <table>
   <tr>
-    <td><ul class="simple">
-	<li>オブジェクトの生成、衝突などにより状態が遷移</li>
-	<li>プレイヤー入力、乱数などの非決定的な要素が多い</li>
-	<br>
-	<li>テストプログラムとして我々が開発したシューティングゲーム
-	  SuperDandy を用意</li>
-	<li>全 5 ステージという、ある程度のボリュームのあるゲーム</li>
-    </ul></td>
     <td>
-      <img src="images/dandy.png" width=300 height=250/>
+      <ul class="simple">
+	<li>自機や敵機、弾丸などの様々な種類のオブジェクトがある</li>
+	<li>プレイヤーの入力により、自機が移動したり弾丸オブジェクトが生成されるなど、ゲームに影響を与える</li>	
+	<li>オブジェクト同士が衝突したり、生成されることでゲームの状態が変化する</li>
+	<li>プレイヤー入力、乱数などの非決定的な要素により、テストの再現性が低下する</li>
+      </ul>
+    </td>
+    <td>
+      <img src="images/game.png" width=300 height=300/>
     </td>
   </tr>
 </table>
 </div>
 
+
 <!--
 <div class="slide">
 <h1>Super Dandy 移植の利点</h1>
@@ -237,7 +248,6 @@
     弾が配列に格納され、敵に当たるか画面外にいくと消滅する。</dd>
 </dl>
 </div>
--->
 
 <div class="slide">
 <h1>Task Dandy(Super Dandy Task version)</h1>
@@ -246,7 +256,7 @@
     <td><ul class="simple">
 	<li>オブジェクトの Move や Collision を Task 化</li>
 	<li>オブジェクトの描画は Cerium による Task を用いた描画処理</li>
-	<li>Super Dandy のコードやデータ構造を流用</li>
+	<li>SuperDandy のコードやデータ構造を流用</li>
     </ul></td>
     <td>
       <img src="images/taskdandy.png" width=250 height=250/>
@@ -254,14 +264,109 @@
   </tr>
 </table>
 </div>
+-->
+
+<div class="slide">
+<h1>目標とするテスト環境</h1>
+<ul class="simple">
+  <li>オブジェクトの生成時と衝突判定して状態変化した時にログを取る
+　<li>Move時にはログを生成しないのでログの量を抑えることが出来る
+  <li>プレイヤーの入力や乱数などの非決定的な要素を固定する
+  <li>移植前後の動作の違いを確認する
+  <li>移植後の逐次実行時と並列実行時による動作の違いを確認する
+  <li>Graphicsを表示しない高速なテストを可能にする
+</ul>
+</div>
 
 <!--
 <div class="slide">
-<h1>目標とするテスト環境</h1>
+<h1>出力されるテストログ</h1>
+<center>
+  <font size="4">
+    <div style="border :2px solid #000000"><pre>
+	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
+        [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
+  </pre></div></font>
+</center>
+<font size="3"><dl class="simple">
+	  <b><dt>F64, F85</dt></b>
+	  <dd>生成、被弾した時の経過フレーム</dd>
+	  <b><dt>CREATE, DELETE</dt></b>
+	  <dd>CREATE はオブジェクトの生成、DELETE はオブジェクトの被弾</dd>
+	  <b><dt>NAME</dt></b>
+	  <dd>オブジェクトの種類と ID</dd>
+	  <b><dt>COORD</dt></b>
+	  <dd>オブジェクトの xy 座標と速度</dd>
+	  <b><dt>BULLET</dt></b>
+	  <dd>その瞬間に画面内に存在した弾丸の数。</dd>
+</dl></font>
+</div>
+-->
+
+<!--
+<font size="3"><ul class="simple">
+  <li>逐次処理では弾の動く処理の後、敵オブジェクトが動く</li>
+  <li>敵オブジェクトが動く前に被弾したため、敵オブジェクトは削除される</li>
+  <li>逐次処理と異なり、並列処理では、敵オブジェクトの処理が弾の動く処理より先に行われる場合がある</li>
+  <li>逐次実行では削除されるはずの敵オブジェクトがそのまま生存する</li>
+</ul></font>
+</div>
+
+<div class="slide">
+<h1>並列処理によるバグ その2</h1>
+<center>
+  <img src="images/parallel_bug2.png" width=300 height=150>
+</center>
+<font size="3"><ul class="simple">
+  <li>敵オブジェクトと発射した弾の衝突判定が行われる</li>
+  <li>逐次実行では敵と弾が衝突したとき、逐次的に両方のオブジェクトの消滅処理が行われる</li>
+  <li>並列処理では敵と弾が衝突したとき、同時に別の敵オブジェクトの衝突判定も行われる</li>
+  <li>このオブジェクトは弾との衝突判定を行い、削除される</li>
+</ul></font>
+</div>
+-->
+
+<div class="slide">
+<h1>プレイヤー入力の固定化の実装</h1>
+<center>
+  <img src="images/cap_trace.png" width=300 height=150>
+</center>
+<font size="3"><ul class="simple">
+  <li>プレイヤーからの入力を 1 フレーム毎に記録する</li>
+  <li>書き出したファイルを読み込むことで過去のプレイヤー入力を再現できる</li>
+  <li>旧バージョンの入力を記録し、新バージョンで読み出すことができる</li>
+  <li>入力が同じでも動作が違えばそこにバグが潜んでいると考えられる</li>
+</ul></font>
+</div>
+
+<!--
+<div class="slide">
+<h1>テスト環境における描画処理</h1>
+<table>
+  <tr>
+    <td><ul class="simple">
+	<li>Cerium を用いたゲームでは画面バッファの確保、描画用の Task の生成により画面を描画する</li>
+	<li>プレイヤーの入力の固定化とテストログ出力により画面描画を行わずにテストができる</li>
+	<li>描画用 Task や画面バッファの生成処理を行わない事により、テストの高速化ができる</li>
+    </ul></td>
+    <td>
+      <img src="images/video2.png" width=300 height=300/>
+    </td>
+  </tr>
+</table>
+</div>
+-->
+
+<!--
+<div class="slide">
+<h1>バグの検出方法</h1>
 <ul class="simple">
-  <li>逐次実行時と並列実行時による動作の違いが確認できる</li>
-  <li>プレイヤーの入力や乱数などの非決定的な要素の固定化</li>
-  <li>高速なテスト環境</li>
+  <li>SuperDandy でプレイヤー入力を記録</li>
+  <li>記録された入力を用いて TaskDandy を実行</li>
+  <li>各バージョンで得られたテストログを比較</li>
+  <li>テストログの違いにより、バグの発生している箇所を特定</li>
 </ul>
 </div>
 -->
@@ -295,33 +400,10 @@
 </table></font>
 </div>
 
-<!--
-<font size="3"><ul class="simple">
-  <li>逐次処理では弾の動く処理の後、敵オブジェクトが動く</li>
-  <li>敵オブジェクトが動く前に被弾したため、敵オブジェクトは削除される</li>
-  <li>逐次処理と異なり、並列処理では、敵オブジェクトの処理が弾の動く処理より先に行われる場合がある</li>
-  <li>逐次実行では削除されるはずの敵オブジェクトがそのまま生存する</li>
-</ul></font>
-</div>
-
-<div class="slide">
-<h1>並列処理によるバグ その2</h1>
-<center>
-  <img src="images/parallel_bug2.png" width=300 height=150>
-</center>
-<font size="3"><ul class="simple">
-  <li>敵オブジェクトと発射した弾の衝突判定が行われる</li>
-  <li>逐次実行では敵と弾が衝突したとき、逐次的に両方のオブジェクトの消滅処理が行われる</li>
-  <li>並列処理では敵と弾が衝突したとき、同時に別の敵オブジェクトの衝突判定も行われる</li>
-  <li>このオブジェクトは弾との衝突判定を行い、削除される</li>
-</ul></font>
-</div>
--->
-
 <div class="slide">
 <h1>並列処理のバグを検出するタイミング</h1>
 <font size="4"><ul class="simple">
-  <li>ゲームの並列処理によるバグは主に衝突判定時に検出される</li>
+  <li>ゲームの並列処理によるバグは主に衝突判定時に検出できる</li>
   <li>ゲームプログラムの状態が遷移する時、バグが検出される</li>
   <li>ゲームの状態が遷移する時(オブジェクトの削除・生成)、テストログを書き出すことにより、
     並列処理のバグを洗い出す</li>
@@ -333,147 +415,45 @@
 	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
-        [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
+                     [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
   </pre></div></font>
 </center>
 </div>
 
-<!--
 <div class="slide">
-<h1>出力されるテストログ</h1>
-<center>
-  <font size="4">
-    <div style="border :2px solid #000000"><pre>
-	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
-        [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-  </pre></div></font>
-</center>
-<font size="3"><dl class="simple">
-	  <b><dt>F64, F85</dt></b>
-	  <dd>生成、被弾した時の経過フレーム</dd>
-	  <b><dt>CREATE, DELETE</dt></b>
-	  <dd>CREATE はオブジェクトの生成、DELETE はオブジェクトの被弾</dd>
-	  <b><dt>NAME</dt></b>
-	  <dd>オブジェクトの種類と ID</dd>
-	  <b><dt>COORD</dt></b>
-	  <dd>オブジェクトの xy 座標と速度</dd>
-	  <b><dt>BULLET</dt></b>
-	  <dd>その瞬間に画面内に存在した弾丸の数。</dd>
-</dl></font>
-</div>
--->
-
-<div class="slide">
-<h1>プレイヤー入力の固定の実装</h1>
-<center>
-  <img src="images/cap_trace.png" width=300 height=150>
-</center>
-<font size="3"><ul class="simple">
-  <li>プレイヤーからの入力を 1 フレーム毎に記録する</li>
-  <li>書き出したファイルを読み込むことで過去のプレイヤー入力を再現できる</li>
-  <li>旧バージョンの入力を記録し、新バージョンで読み出すことができる</li>
-  <li>入力が同じでも動作が違えばそこにバグが潜んでいると考えられる</li>
-</ul></font>
-</div>
+<h1>SuperDandyの逐次実行と並列実行の比較</h1>
+<font size="3"><div style="border :2px solid #000000"><pre>
+super dandy >>
+F109: DELETE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -24.000000 ...
+              [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
+F117: DELETE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= 40.000000 ...
+              [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
 
-<div class="slide">
-<h1>SPE 内での予測可能な乱数の使用</h1>
-<table>
-  <tr>
-    <td><font size="4"><ul class="simple">
-	  <li>シーケンシャルプログラムでは 1 つの乱数列から順番に乱数を取得</li>
-	  <li>Cell における並列プログラムでは各 SPE 内で 独自の乱数列を生成</li>
-	  <li>シーケンシャルと並列で異なる結果が出る</li>
-    </ul></font></td>
-    <td>
-      <img src="images/spe_random.png" width=350 height=250/>
-    </td>
-  </tr>
-</table>
-</div>
-
-<div class="slide">
-<h1>SPE 内での予測可能な乱数の使用</h1>
-<table>
-  <tr>
-    <td><ul class="simple">
-	<li>あらかじめ PPE 内で乱数列を生成しておく</li>
-	<li>入力データとして Task に渡す</li>
-	<li>Task の生成タイミングは Super Dandy の Move や Collision と同じ</li>
-	<li>Super Dandy と同じ乱数が使用できる</li>
-    </ul></td>
-    <td>
-      <img src="images/spe_random.png" width=350 height=250/>
-    </td>
-  </tr>
-</table>
-</div>
-
-<!--
-<div class="slide">
-<h1>テスト環境における描画処理</h1>
-<table>
-  <tr>
-    <td><ul class="simple">
-	<li>Cerium を用いたゲームでは画面バッファの確保、描画用の Task の生成により画面を描画する</li>
-	<li>プレイヤーの入力の固定化とテストログ出力により画面描画を行わずにテストができる</li>
-	<li>描画用 Task や画面バッファの生成処理を行わない事により、テストの高速化ができる</li>
-    </ul></td>
-    <td>
-      <img src="images/video2.png" width=300 height=300/>
-    </td>
-  </tr>
-</table>
-</div>
--->
-
-<div class="slide">
-<h1>バグの検出方法</h1>
+<< task dandy
+F109: DELETE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -24.000000 ...
+              [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
+F109: DELETE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= -24.000000 ...
+              [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
+</pre></div></font>
 <ul class="simple">
-  <li>SuperDandy でプレイヤー入力を記録</li>
-  <li>記録された入力を用いて TaskDandy を実行</li>
-  <li>各バージョンで得られたテストログを比較</li>
-  <li>テストログの違いにより、バグの発生している箇所を特定</li>
+  <li>逐次実行時に別フレームで死んだ2つの敵オブジェクトが並列処理では同フレームで死亡</li>
+  <li>片方が死んだ後、弾丸のオブジェクトの除去がされてない</li>
+  <li>各オブジェクトのCollision Taskの間で弾丸データの同期が取れていない</li>
 </ul>
 </div>
 
 <div class="slide">
-<h1>SuperDandy と TaskDandy の比較</h1>
-<font size="3"><div style="border :2px solid #000000"><pre>
-super dandy >>
-F109: DELETE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -24.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-F117: DELETE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= 40.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-
-<< task dandy
-F109: DELETE  [NAME]enemy_greenclab_1  [COORD]x= 56.000000  y= -24.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-F109: DELETE  [NAME]enemy_greenclab_2  [COORD]x= 184.000000  y= -24.000000 ...
-             [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
-</pre></div></font>
-<ul class="simple">
-  <li>SuperDandy では別フレームで死んだ 2 つの敵オブジェクトが TaskDandy では
-  同フレームで死亡</li>
-  <li>片方が死んだ後、弾丸のオブジェクトの除去がされてない</li>
-  <li>弾丸データの同期が取れていない</li>
-</ul>
-</div>
-
-<div class="slide">
-<h1>Collision Task 間でのデータの同期</h1>
+<h1>Collision Task間でのデータの同期</h1>
 <table>
   <tr>
     <td><ul class="simple">
-	<li>Collision Task を同じ CPU に送る</li>
-	<li>予め衝突判定に必要なパラメータの領域を確保する</li>
-	<li>その領域のパラメータで衝突判定を行う</li>
-	<li>SPE 内で変更されたパラメータをメインメモリ側に反映させる</li>
+	<li>予め衝突判定に必要なデータをCPUに送っておく</li>
+	<li>Collision Taskを同じCPUに送る</li>
+	<li>Taskで送られたデータを用いて衝突判定を行う</li>
+	<li>同じCPU上なのでCollision Task間でパラメータの共有ができる</li>
     </ul></td>
     <td>
-      <img src="images/collision_reflect.png" width=300 height=300/>
+      <img src="images/collision_uml.png" width=300 height=300/>
     </td>
   </tr>
 </table>
@@ -495,13 +475,14 @@
              [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
 </pre></div></font>
 <ul class="simple">
-  <li>2 つのバージョンのログがフレーム単位で同じ</li>
-  <li>Collision Task のデータ同期によるバグの除去</li>
+  <li>2 つのバージョンにおけるオブジェクトの衝突判定が一致している</li>
+  <li>また、弾丸オブジェクトの個数も一致している</li>
+  <li>Collision Task のデータ同期が正しく行われていることがわかる</li>
 </ul>
 </div>
 
 <div class="slide">
-<h1>隕石オブジェクトによる乱数の検証</h1>
+<h1>ゲーム内の乱数のテストへの影響</h1>
 <div style="border :2px solid #000000"><font size="2"><pre>
   int sf = random() % 4;
 
@@ -522,17 +503,49 @@
       .....
 </pre></font></div>
 <ul class="simple">
-  <li>乱数によって初期配置が変わる隕石オブジェクトを用いて検証</li>
-  <li>乱数によって決定される条件式を持つ</li>
-  <li>また、乱数によって配置される座標が変化する</li>
-  <li>逐次実行させた場合と並列実行させた場合を比較</li>
+  <li>乱数によって決定される条件式を持つ
+  <li>乱数を固定化すると、テストのカバレッジが不十分になる可能性がある
+  <li>Taskが逐次実行と並列実行で異なる乱数を使用する場合があり、テストの再現性がなくなる
 </ul>
 </div>
 
 <div class="slide">
+<h1>PS3での予測可能な乱数の使用</h1>
+<table>
+  <tr>
+    <td><font size="4"><ul class="simple">
+	  <li>シーケンシャルなゲームプログラムでは 1 つの乱数列から順番に乱数を取得</li>
+	  <li>PS3におけるTaskによる並列実行では各CPU内で独自の乱数列を生成</li>
+	  <li>逐次実行と並列実行で異なる乱数を使用するので、実行した結果が異なる</li>
+    </ul></font></td>
+    <td>
+      <img src="images/spe_random.png" width=350 height=250/>
+    </td>
+  </tr>
+</table>
+</div>
+
+<div class="slide">
+<h1>PS3での予測可能な乱数の使用</h1>
+<table>
+  <tr>
+    <td><ul class="simple">
+	<li>あらかじめメインのCPU内で乱数列を生成しておく</li>
+	<li>Taskを生成した際に列から乱数を取得し、渡しておく</li>
+	<li>Taskの生成タイミングはSuper DandyのMoveやCollisionと同じ</li>
+	<li>Super Dandyと同じ乱数が使用できる</li>
+    </ul></td>
+    <td>
+      <img src="images/spe_random.png" width=350 height=250/>
+    </td>
+  </tr>
+</table>
+</div>
+
+<div class="slide">
 <h1>実行結果</h1>
 <div style="border :2px solid #000000"><font size="3"><pre>
-demolog >>
+super dandy >>
 [ID]1  [COORD]x= -35.000000  y= 20.000000  vx= 3.000000  vy= 1.000000
 ...
 [ID]6  [COORD]x= 220.000000  y= -30.000000  vx= 1.000000  vy= 4.000000
@@ -540,15 +553,16 @@
 [ID]11  [COORD]x= -35.000000  y= 57.000000  vx= 3.000000  vy= 3.000000
 ...
 
-<< tdandylog
+<< task dandy
+[ID]1  [COORD]x= -35.000000  y= 20.000000  vx= 3.000000  vy= 1.000000
 [ID]6  [COORD]x= 220.000000  y= -30.000000  vx= 1.000000  vy= 4.000000
 [ID]11  [COORD]x= -35.000000  y= 57.000000  vx= 3.000000  vy= 3.000000
-[ID]1  [COORD]x= -35.000000  y= 20.000000  vx= 3.000000  vy= 1.000000
 ...
 </pre></font></div>
 <ul class="simple">
-  <li>同一の ID を持つオブジェクト同士では、パラメータが一致している</li>
-  <li>Task への乱数受け渡しによる固定化が行われている</li>
+  <li>同一のIDを持つオブジェクト同士では、座標や速さの値が一致している</li>
+  <li>Taskへの乱数受け渡しによる固定化が行われている</li>
+  <li>乱数による条件分岐におけるカバレッジのカバーができている</li>
 </ul>
 </div>
 
@@ -565,7 +579,7 @@
 <div class="slide">
 <h1>描画の有無による実行時間の比較</h1>
 <font size="4">
-<h2>プレイヤー入力の固定化により描画処理を省略することができる</h2>
+<h2>プレイヤー入力の固定化により描画処理を省略し、テストを高速に行うことができる</h2>
 </font>
 <center>
 <table border="1" cellspacing="0">
@@ -585,18 +599,20 @@
 
 <div class="slide">
 <h1>まとめ</h1>
-<!--<h2>本研究では並列環境におけるゲームプログラムのテスト手法を提案した</h2>-->
+<h2>本研究では並列環境におけるゲームプログラムのテスト手法を提案した</h2>
 <ul class="simple">
-  <li>ゲームにおけるランダム要素であるプレイヤー入力、乱数生成を固定化した</li>
-  <li>ゲームの状態遷移時におけるバグの検出を行った</li>
-  <li>描画の除去によるテストの高速化を行った</li>
-  <br>
-  <li>ゲームの状態遷移数を数えることにより、ゲーム内の全ての状態をテストできる</li>
-  <li>並列環境上における、ゲームプログラムのテストを自動化する事が可能</li>
-  <li>今後はゲームの状態遷移数の数え上げを行う</li>
+  <li>ゲームにおける非決定的な要素であるプレイヤー入力、乱数生成を固定化し、
+  Single Trace の再現性を保証した</li>
+  <li>ゲームの状態遷移時においてテストログを出力することにより、
+    シーケンシャルなプログラムを Task に分割し、並列実行した時に
+    発生するバグを検出、修正した</li>
 </ul>
 </div>
 
+<div class="slide">
+<h1>今後の課題</h1>
+<ul class="simple">
+  <li>プログラムのカバレッジのカバー、およびカバー率の測定を行う
+  <li>ゲームの状態遷移を数え上げることにより、ゲームの動作全体の比較を可能にする</li>
+</ul>
 </div>
-</body>
-</html>