# HG changeset patch
# User koba <koba@cr.ie.u-ryukyu.ac.jp>
# Date 1299408434 -32400
# Node ID 7ea21aa275eb6da00ad75f80c4c2e6d2c596ea00
# Parent  7b20f8b4d6971afcfe91c9ec3fe08cad3b771f2f
pre finish.

diff -r 7b20f8b4d697 -r 7ea21aa275eb presen/sigss-presen.html
--- a/presen/sigss-presen.html	Sun Mar 06 17:29:49 2011 +0900
+++ b/presen/sigss-presen.html	Sun Mar 06 19:47:14 2011 +0900
@@ -47,6 +47,7 @@
 <h4>指導教員:河野　真治</h4>
 </div>
 
+<!--
 <div class="slide">
 <h1>発表内容</h1>
 <ol>
@@ -59,6 +60,7 @@
 <li>まとめ</li>
 </ol>
 </div>
+-->
 
 <div class="slide">
 <h1>研究背景</h1>
@@ -79,15 +81,14 @@
 </div>
 
 <div class="slide">
-<h1>研究目的</h1>
+<h1>研究概要</h1>
 <font size="4"><ul>
 <li>本研究では Task に分割されたゲームプログラムがシーケンシャルなバージョン
-と同じ動作である事を確認できるテスト環境の構築を目的とする。</li>
-<li>プレイヤーの入力や乱数などの非決定的な要素を固定化し、バグの再現性を
-低下させずにテストを行えるようにする。</li>
-<li>動作の同一性を確かめるために必要なパラメータの書き出しを行う</li>
+と同じ動作である事を確認できるテスト環境を構築した</li>
+<li>プレイヤーの入力や乱数などの非決定的な要素を固定化した</li>
+<li>動作の同一性を確かめるために必要なパラメータの書き出しを行った</li>
 <li>高速なテストを行う為、テストに影響しない範囲で実行時間が大きい処理を
-排除する。</li>
+排除した</li>
 </ul></font>
 </div>
 
@@ -117,6 +118,7 @@
 </dl>
 </div>
 
+<!--
 <div class="slide">
 <h1>Task に設定できる項目</h1>
 <ul class="simple">
@@ -128,7 +130,6 @@
 </ul>
 </div>
 
-<!--
 <div class="slide">
 <h1>CppUnit</h1>
 <ul class="simple">
@@ -152,15 +153,15 @@
 <li>一般的な単体テストではゲームのバグの発見は難しい</li>
 </ul>
 </div>
--->
 
 <div class="slide">
 <h1>ゲームプログラムの特徴</h1>
 <ul class="simple">
-  <li>プレイヤーの入力がゲームに影響する</li>
+  <li>プレイヤー入力によるゲーム内容への影響</li>
+  <li>乱数によるゲーム内容の多様性</li>
   <li>オブジェクトの生成、衝突などの遷移する状態が膨大</li>
   <li>遷移する状態が仕様の範囲内に収まるかをチェックするテストは向かない</li>
-  <li>実際にプレイヤーがゲームをプレイするのが重要なテスト</li>
+  <li>プレイヤー入力、乱数などのランダム要素</li>
 </ul>
 </div>
 
@@ -184,16 +185,20 @@
   <li>対処法としては、乱数生成器を無効にするか、定数でシードする</li>
 </ul>
 </div>
+-->
 
 <div class="slide">
-<h1>シューティングゲーム SuperDandy</h1>
+<h1>ゲームプログラムの特徴</h1>
 <table>
   <tr>
     <td><ul class="simple">
-	<li>我々が PlayStation 上でのゲーム開発を行っていた 1998 年に開発</li>
-	<li>タイトルからゲーム本編中の敵機の登場、ステージクリア、エンディングと
-	  ゲーム的な要素が多い</li>
-	<li>PlayStation, PlayStation2 Linux, OpenGL と伝統的に移植されてきた</li>
+	<li>プレイヤー入力によるゲーム内容への影響</li>
+	<li>オブジェクトの生成、衝突などにより状態が遷移</li>
+	<li>プレイヤー入力、乱数などのランダム要素</li>
+	<br>
+	<li>テストプログラムとして我々が開発したシューティングゲーム
+	  SuperDandy を用意</li>
+	<li>全 5 ステージという、ある程度のボリュームのあるゲーム</li>
     </ul></td>
     <td>
       <img src="images/dandy.png" width=300 height=250/>
@@ -202,6 +207,7 @@
 </table>
 </div>
 
+<!--
 <div class="slide">
 <h1>Super Dandy 移植の利点</h1>
 <ul class="simple">
@@ -210,6 +216,7 @@
   <li>動作結果を過去の環境と比較することによる新たな環境のチューニングができる</li>
 </ul>
 </div>
+-->
 
 <!--
 <div class="slide">
@@ -234,7 +241,7 @@
   <tr>
     <td><ul class="simple">
 	<li>オブジェクトの Move や Collision を Task 化</li>
-	<li>オブジェクトの描画は SceneGraph tree の形成、Rendering Task の
+	<li>オブジェクトの描画は SceneGraph tree の形成、描画用 Task の
 	  生成といった Cerium の描画処理を使用</li>
 	<li>Super Dandy のコードやデータ構造を流用</li>
     </ul></td>
@@ -255,14 +262,39 @@
 </div>
 
 <div class="slide">
-<h1>並列処理によるバグ その1</h1>
-<center>
-  <img src="images/parallel_bug1.png" width=300 height=150>
-</center>
+<h1>並列処理によるバグ</h1>
+<table>
+  <tr>
+    <td><ul class="simple">
+	<li>逐次処理と異なり、並列処理では、敵オブジェクトの処理が弾の動く処理より先に行われる場合がある</li>
+	<li>逐次実行では削除されるはずの敵オブジェクトがそのまま生存する</li>
+    </ul></td>
+    <td>
+      <center>
+	<img src="images/parallel_bug1.png" width=300 height=150>
+      </center>
+    </td>
+  </tr>
+  <tr>
+      <td><ul class="simple">
+	<li>並列処理では敵と弾が衝突したとき、同時に別の敵オブジェクトの衝突判定も行われる</li>
+	<li>逐次実行では生存するはずの敵オブジェクトが削除される</li>
+    </ul></td>
+    <td>
+      <center>
+	<img src="images/parallel_bug2.png" width=300 height=150>
+      </center>
+    </td>
+  </tr>
+
+</table>
+
+<!--
 <font size="3"><ul class="simple">
+
   <li>逐次処理では弾の動く処理の後、敵オブジェクトが動く</li>
   <li>敵オブジェクトが動く前に被弾したため、敵オブジェクトは削除される</li>
-  <li>並列処理では、敵オブジェクトの処理が弾の動く処理より先に行われる場合がある</li>
+  <li>逐次処理と異なり、並列処理では、敵オブジェクトの処理が弾の動く処理より先に行われる場合がある</li>
   <li>逐次実行では削除されるはずの敵オブジェクトがそのまま生存する</li>
 </ul></font>
 </div>
@@ -270,7 +302,6 @@
 <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>
@@ -279,45 +310,57 @@
   <li>このオブジェクトは弾との衝突判定を行い、削除される</li>
 </ul></font>
 </div>
+-->
 
 <div class="slide">
 <h1>並列処理のバグを検出するタイミング</h1>
 <font size="4"><ul class="simple">
   <li>ゲームの並列処理によるバグは主に衝突判定時に検出される</li>
   <li>ゲームプログラムの状態が遷移する時、バグが検出される</li>
-  <li>ゲームの状態が遷移する時(オブジェクトの削除・生成)、テストログを書き出す</li>
-  <li>これにより並列処理のバグを洗い出す</li>
+  <li>ゲームの状態が遷移する時(オブジェクトの削除・生成)、テストログを書き出すことにより、
+    並列処理のバグを洗い出す</li>
 </ul></font>
+<br>
+<center>
+  <font size="3">
+    <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>
 </div>
 
+<!--
 <div class="slide">
 <h1>出力されるテストログ</h1>
 <center>
-<font size="2">
-<div style="border :1px 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>
+  <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>
+	  <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>Capture モードと Trace モード</h1>
+<h1>プレイヤー入力の固定の実装</h1>
 <center>
   <img src="images/cap_trace.png" width=300 height=150>
 </center>
@@ -363,31 +406,13 @@
 </div>
 
 <div class="slide">
-<h1>Cerium における画面の描画処理</h1>
-<table>
-  <tr>
-    <td><ul class="simple">
-	<li>ビデオモードの選択(SDL, OpenGL)</li>
-	<li>描画処理を行う画面バッファの領域の確保</li>
-	<li>ゲーム処理の実行</li>
-	<li>レンダリング Task による画面バッファへの描画</li>
-    </ul></td>
-    <td>
-      <img src="images/video.png" width=300 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>
+	<li>Cerium を用いたゲームでは画面バッファの確保、描画用の Task の生成により画面を描画する</li>
+	<li>プレイヤーの入力の固定化とテストログ出力により画面描画を行わずにテストができる</li>
+	<li>描画用 Task や画面バッファの生成処理を行わない事により、テストの高速化ができる</li>
     </ul></td>
     <td>
       <img src="images/video2.png" width=300 height=300/>
@@ -397,19 +422,19 @@
 </div>
 
 <div class="slide">
-<h1>バグの検出実験</h1>
+<h1>バグの検出方法</h1>
 <ul class="simple">
-  <li>OpenGL バージョンを Capture モードでプレイし、入力を記録</li>
-  <li>記録された入力を用いて Task Dandy を Trace モードで実行</li>
-  <li>各バージョンで得られたテストログを比較、考察</li>
+  <li>SuperDandy でプレイヤー入力を記録</li>
+  <li>記録された入力を用いて TaskDandy を実行</li>
+  <li>各バージョンで得られたテストログを比較</li>
   <li>テストログの違いにより、バグの発生している箇所を特定</li>
 </ul>
 </div>
 
 <div class="slide">
 <h1>SuperDandy と TaskDandy の比較</h1>
-<font size="4"><pre>
-super dandy(OpenGL) >>
+<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 ...
@@ -420,13 +445,12 @@
              [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></font>
+</pre></div></font>
 <ul class="simple">
-  <li>OpenGL では別フレームで死んだ 2 つの敵オブジェクトが Task Dandy では
+  <li>SuperDandy では別フレームで死んだ 2 つの敵オブジェクトが TaskDandy では
   同フレームで死亡</li>
-  <li>この時の弾丸の数が一致</li>
   <li>片方が死んだ後、弾丸のオブジェクトの除去がされてない</li>
-  <li>弾丸データが取れていない</li>
+  <li>弾丸データの同期が取れていない</li>
 </ul>
 </div>
 
@@ -449,8 +473,8 @@
 
 <div class="slide">
 <h1>Collision Task の改良後の比較</h1>
-<font size="4"><pre>
-super dandy(OpenGL) >>
+<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 ...
@@ -461,30 +485,18 @@
              [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
-</pre></font>
+</pre></div></font>
 <ul class="simple">
   <li>2 つのバージョンのログがフレーム単位で同じ</li>
-  <li>Collision Task のデータ同期が有効に働いている</li>
+  <li>Collision Task のデータ同期によるバグの除去</li>
 </ul>
 </div>
 
 <div class="slide">
-<h1>Task への乱数受け渡しの検証</h1>
-<ul class="simple">
-  <li>乱数によって初期配置が変わる隕石オブジェクトを用いて検証</li>
-  <li>多数の隕石オブジェクトが生成されるステージで全ての隕石オブジェクトが
-  生成されるのを観察</li>
-  <li>隕石オブジェクト生成後のパラメータを出力</li>
-  <li>逐次実行させた場合と並列実行させた場合を比較</li>
-</ul>
-</div>
+<h1>隕石オブジェクトによる乱数の検証</h1>
+<div style="border :2px solid #000000"><font size="2"><pre>
+  int sf = random() % 4;
 
-<div class="slide">
-<h1>隕石オブジェクトの実装</h1>
-<font size="4"><pre>
-  int sf;
-
-  sf = random() % 4;
   if((sf == 0) || (sf == 1))
     {
       p->x = -35;
@@ -500,14 +512,19 @@
   if(sf == 3)
     {
       .....
-</pre></font>
+</pre></font></div>
+<ul class="simple">
+  <li>乱数によって初期配置が変わる隕石オブジェクトを用いて検証</li>
+  <li>乱数によって決定される条件式を持つ</li>
+  <li>また、乱数によって配置される座標が変化する</li>
+  <li>逐次実行させた場合と並列実行させた場合を比較</li>
+</ul>
 </div>
 
 <div class="slide">
 <h1>実行結果</h1>
-<font size="4"><pre>
+<div style="border :2px solid #000000"><font size="3"><pre>
 demolog >>
-[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
@@ -520,9 +537,14 @@
 [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>
+</pre></font></div>
+<ul class="simple">
+  <li>同一の ID を持つオブジェクト同士では、パラメータが一致している</li>
+  <li>Task への乱数受け渡しによる固定化が行われている</li>
+</ul>
 </div>
 
+<!--
 <div class="slide">
 <h1>乱数受け渡しによる実行結果の検証</h1>
 <ul class="simple">
@@ -530,28 +552,21 @@
   <li>Task への乱数受け渡しによるバグの再現性の低下防止は有効である</li>
 </ul>
 </div>
+-->
 
 <div class="slide">
 <h1>ビデオモードによる実行時間の比較</h1>
-<ul class="simple">
-  <li>実行時間の計測には unix の time コマンドを使用</li>
-  <li>オリジナルである OpenGL バージョン、Cerium による描画バージョン、描画無しバージョンで計測</li>
-</ul>
-</div>
-
-<div class="slide">
-<h1>実行結果</h1>
+<p>SuperDandy と TaskDandy の描画の有無による実行時間を観測</p>
 <center>
 <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>
+  <tr><td></td><!--<th>SuperDandy</th>--><th>TaskDandy</th><th>TaskDandy(no video)</th></tr>
+  <tr><th>実行時間</th><!--<td>336.09 sec</td>--><td>6643.16 sec</td><td>385.17 sec</td></tr>
 </table>
 </center>
 <ul class="simple">
-  <li>Task バージョンは劇的に処理時間が増加した</li>
-  <li>OpenGL は GPU を使用し、TaskDandy はソフトウェアレンダリングである</li>
-  <li>TaskDandy では Cerium における Task の処理が発生したため、実行時間が大きく増加したと考えられる</li>
-  <li>描画処理の Task に比べればゲームの Task は処理が小さい</li>
+  <li>描画を行わないことにより、処理時間が大幅に減少した</li>
+  <li>描画処理 Task の処理時間が非常に大きい</li>
+  <li>Cerium のチューニングにより実行時間は減少する</li>
 </ul>
 </div>
 
@@ -559,12 +574,16 @@
 </div>
 
 <div class="slide">
-<h1>結論</h1>
-<h2>本研究では並列環境におけるゲームプログラムのテスト手法を提案した</h2>
+<h1>まとめ</h1>
+<!--<h2>本研究では並列環境におけるゲームプログラムのテスト手法を提案した</h2>-->
 <ul class="simple">
   <li>ゲームの状態遷移時におけるバグの検出を行った</li>
   <li>ゲームにおけるランダム要素であるプレイヤー入力、乱数生成を固定化した</li>
-  <li></li>
+  <li>描画の除去によるテストの高速化を行った</li>
+  <br>
+  <li>ゲームの状態遷移数を数えることにより、ゲーム内の全ての事象をテストできる</li>
+  <li>並列環境上における、ゲームプログラムのテストを自動化する事が可能</li>
+  <li>今後はゲームの状態遷移数の数え上げを行う</li>
 </ul>
 </div>