# HG changeset patch
# User koba <koba@cr.ie.u-ryukyu.ac.jp>
# Date 1297975177 -32400
# Node ID c20d7b72cd4a55b33c0ff9a08b6679f2bca32a7a
# Parent  a5fb2dea1c60621ea7fc6dd931c96ff30a7f7d93
finish?

diff -r a5fb2dea1c60 -r c20d7b72cd4a poster/master-lt.html
--- 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>
 
diff -r a5fb2dea1c60 -r c20d7b72cd4a poster/master-poster.pdf
Binary file poster/master-poster.pdf has changed
diff -r a5fb2dea1c60 -r c20d7b72cd4a presen/master-presen.html
--- a/presen/master-presen.html	Thu Feb 17 14:49:08 2011 +0900
+++ b/presen/master-presen.html	Fri Feb 18 05:39:37 2011 +0900
@@ -29,7 +29,7 @@
 <div id="currentSlide"><!-- DO NOT EDIT --></div>
 <div id="header"></div>
 <div id="footer">
-<h1>[date:11/02/09]</h1>
+<h1>[date:11/02/18]</h1>
 <h2>Game Framework Cerium を用いたゲームプログラミングにおけるテスト手法の提案</h2>
 </div>
 
@@ -548,7 +548,7 @@
 </center>
 <ul class="simple">
   <li>Cerium バージョンは描画を行わないモードで実行</li>
-  <li>エンディングまでプレイした入力データを仕様</li>
+  <li>エンディングまでプレイした入力データを使用</li>
   <li>テストログのデータに unix コマンドの wc(word count) コマンドを実行して検証</li>
   <li>各バージョンで得られたテストログを比較、考察</li>
 </ul>
@@ -584,13 +584,13 @@
 > 0.000000 FPS
 > game end
 </pre></font>
-<ul class="simple">
+<font size="4"><ul class="simple">
   <li>表示されているメッセージは OpenGL や Cerium 依存のメッセージ</li>
   <li>0.000000 FPS は Cerium 側のメッセージで描画を行わないビデオモードにより
   正しく FPS の計算ができなかったため</li>
   <li>wc の単語数はスペース区切りで判別するため、Cerium=6,OpenGL=5</li>
   <li>よって両バージョンの動作は同じである</li>
-</ul>
+</ul></font>
 </div>
 
 <div class="slide">
@@ -779,27 +779,19 @@
 <h1>実行結果</h1>
 <font size="4"><pre>
 demolog >>
-[COORD]x= 320.000000  y= 66.000000  vx= -2.000000  vy= 0.000000
-[COORD]x= -35.000000  y= 20.000000  vx= 3.000000  vy= 1.000000
-[COORD]x= -35.000000  y= 36.000000  vx= 3.000000  vy= 2.000000
-[COORD]x= 89.000000  y= -30.000000  vx= 1.000000  vy= 3.000000
-[COORD]x= -35.000000  y= 81.000000  vx= 1.000000  vy= 2.000000
-[COORD]x= 320.000000  y= 8.000000  vx= -4.000000  vy= -1.000000
-[COORD]x= 220.000000  y= -30.000000  vx= 1.000000  vy= 4.000000
-....
+[ID]0  [COORD]x= 320.000000  y= 66.000000  vx= -2.000000  vy= 0.000000
+[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
+...
 
 << tdandylog
-[COORD]x= 320.000000  y= 66.000000  vx= -2.000000  vy= 0.000000
-[COORD]x= -35.000000  y= 20.000000  vx= 3.000000  vy= 1.000000
-[COORD]x= -35.000000  y= 36.000000  vx= 3.000000  vy= 2.000000
-[COORD]x= 89.000000  y= -30.000000  vx= 1.000000  vy= 3.000000
-[COORD]x= -35.000000  y= 81.000000  vx= 1.000000  vy= 2.000000
-[COORD]x= 320.000000  y= 8.000000  vx= -4.000000  vy= -1.000000
-[COORD]x= 220.000000  y= -30.000000  vx= 1.000000  vy= 4.000000
-....
-
-% diff demolog tdandylog
-%
+[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>
 
@@ -823,7 +815,7 @@
 <div class="slide">
 <h1>実行結果</h1>
 <table border="1" cellspacing="0">
-  <tr><td></td><th>OpenGL(w=1,h=1)</th><th>Cerium(no video)</th><th>Task(no video)</th><th>OpenGL</th><th>Cerium</th><th>Task</th></tr>
+  <tr><td></td><th>OpenGL<br>(w=1,h=1)</th><th>Cerium(no video)</th><th>Task(no video)</th><th>OpenGL</th><th>Cerium</th><th>Task</th></tr>
   <tr><th>実行時間</th><td>335.06 sec</td><td>334.21 sec</td><td>385.17 sec</td><td>336.09 sec</td><td>5066.11 sec</td><td>6643.16 sec</td></tr>
 </table>
 <ul class="simple">
@@ -836,7 +828,7 @@
 <div class="slide">
 <h1>実行結果</h1>
 <table border="1" cellspacing="0">
-  <tr><td></td><th>OpenGL(w=1,h=1)</th><th>Cerium(no video)</th><th>Task(no video)</th><th>OpenGL</th><th>Cerium</th><th>Task</th></tr>
+  <tr><td></td><th>OpenGL<br>(w=1,h=1)</th><th>Cerium(no video)</th><th>Task(no video)</th><th>OpenGL</th><th>Cerium</th><th>Task</th></tr>
   <tr><th>実行時間</th><td>335.06 sec</td><td>334.21 sec</td><td>385.17 sec</td><td>336.09 sec</td><td>5066.11 sec</td><td>6643.16 sec</td></tr>
 </table>
 <ul class="simple">