# HG changeset patch
# User koba <koba@cr.ie.u-ryukyu.ac.jp>
# Date 1299425903 -32400
# Node ID 7e707cabd73a52643cf8f690bda4864fd5ab8325
# Parent  7ea21aa275eb6da00ad75f80c4c2e6d2c596ea00
fix(not finish).

diff -r 7ea21aa275eb -r 7e707cabd73a presen/sigss-presen.html
--- a/presen/sigss-presen.html	Sun Mar 06 19:47:14 2011 +0900
+++ b/presen/sigss-presen.html	Mon Mar 07 00:38:23 2011 +0900
@@ -39,12 +39,13 @@
 <div class="presentation">
 
 <div class="slide">
-<h1>Game Framework Cerium を用いた<br>
-    ゲームプログラミングにおける<br>
-    テスト手法の提案</h1>
-<h3>発表者:小林　佑亮</h3>
-<h4>所属:琉球大学 理工学研究科 情報工学専攻 並列信頼研究室</h4>
-<h4>指導教員:河野　真治</h4>
+<h1>GameFrameWork Cerium における<br>
+    Sequential な Game Program の分割と<br>
+    動作の検証</h1>
+
+<h3>小林　佑亮</h3>
+<h4>多賀野 海人　金城 裕　河野 真治</h4>
+<h4>琉球大学 理工学研究科 並列信頼研究室</h4>
 </div>
 
 <!--
@@ -63,35 +64,25 @@
 -->
 
 <div class="slide">
-<h1>研究背景</h1>
-<font size="4"><ul>
-<li>我々は PlayStation3(以下 PS3) 上においてゲーム開発が行えるフレームワーク
- Cerium を開発した。</li>
-<li>Cerium ではプログラムを Task という単位に分けて管理し、これを PS3 の 
-アーキテクチャである Cell B.E に渡して並列処理を行う。</li>
+<h1>研究要旨</h1>
+<font size="3"><ul>
+<li>我々は PlayStation3(以下 PS3) のマルチコアアーキテクチャ Cell B.E を用いて
+  並列処理を行うゲームフレームワーク Cerium を開発した。Cerium では
+  プログラムを Task という単位に分け、Cell B.E に渡して並列処理を行う。</li>
 <li>シーケンシャルなプログラムを Task に分割して並列実行させても、
-逐次実行させた時と同じ動作をするとは限らない。</li>
-<li>オブジェクト同士のデータの同期や、処理の実行順序など、シーケンシャルな
-プログラムに比べて、バグを発生させる要因は多い。</li>
-<li>また、ゲームプログラムの特徴はプレイヤーの入力やプログラム内にある乱数
-などの非決定的な要素が多いことが挙げられる。</li>
-<li>これによってバグの再現性が低下するため、ゲームプログラムのテストは
-  一般的なソフトウェアのテストに比べて難しい</li>
+  データの同期や実行順序の違いなどにより逐次実行させた時と同じ動作をするとは
+  限らない。また、ゲームプログラムにはプレイヤーの入力や乱数などの非決定的な
+  要素が多く、バグの再現性が低い。</li>
+<br>
+<li>本研究ではシーケンシャルなゲームプログラムを逐次実行した時と Task に分割
+  した時の動作が同一である事を確認できるテスト環境を構築する。
+  ゲームプログラムにおける非決定的な要素を固定化し、ゲームの状態遷移時に
+  おいてバグの検出を行うことで並列実行時のバグを発見する。</li>
+<li>ゲームの状態数を数え上げ</li>
 </ul></font>
 </div>
 
-<div class="slide">
-<h1>研究概要</h1>
-<font size="4"><ul>
-<li>本研究では Task に分割されたゲームプログラムがシーケンシャルなバージョン
-と同じ動作である事を確認できるテスト環境を構築した</li>
-<li>プレイヤーの入力や乱数などの非決定的な要素を固定化した</li>
-<li>動作の同一性を確かめるために必要なパラメータの書き出しを行った</li>
-<li>高速なテストを行う為、テストに影響しない範囲で実行時間が大きい処理を
-排除した</li>
-</ul></font>
-</div>
-
+<!--
 <div class="slide">
 <h1>Cell Broadband Engine</h1>
 <center>
@@ -105,9 +96,24 @@
     繋がっている</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>
+</div>
+
+<!--
+<div class="slide">
+<h1>Game Framework Cerium</h1>
 <dl>
   <b><dt>SceneGraph</dt></b>
   <dd>オブジェクトのパラメータやポリゴン情報を tree 構造のノードで管理</dd>
@@ -117,6 +123,7 @@
   <dd>Task を動的に SPE へ割り振るカーネルとして振舞う</dd>
 </dl>
 </div>
+-->
 
 <!--
 <div class="slide">
@@ -153,15 +160,13 @@
 <li>一般的な単体テストではゲームのバグの発見は難しい</li>
 </ul>
 </div>
+-->
 
+<!--
 <div class="slide">
 <h1>ゲームプログラムの特徴</h1>
 <ul class="simple">
-  <li>プレイヤー入力によるゲーム内容への影響</li>
-  <li>乱数によるゲーム内容の多様性</li>
-  <li>オブジェクトの生成、衝突などの遷移する状態が膨大</li>
-  <li>遷移する状態が仕様の範囲内に収まるかをチェックするテストは向かない</li>
-  <li>プレイヤー入力、乱数などのランダム要素</li>
+
 </ul>
 </div>
 
@@ -192,9 +197,8 @@
 <table>
   <tr>
     <td><ul class="simple">
-	<li>プレイヤー入力によるゲーム内容への影響</li>
 	<li>オブジェクトの生成、衝突などにより状態が遷移</li>
-	<li>プレイヤー入力、乱数などのランダム要素</li>
+	<li>プレイヤー入力、乱数などの非決定的な要素が多い</li>
 	<br>
 	<li>テストプログラムとして我々が開発したシューティングゲーム
 	  SuperDandy を用意</li>
@@ -241,8 +245,7 @@
   <tr>
     <td><ul class="simple">
 	<li>オブジェクトの Move や Collision を Task 化</li>
-	<li>オブジェクトの描画は SceneGraph tree の形成、描画用 Task の
-	  生成といった Cerium の描画処理を使用</li>
+	<li>オブジェクトの描画は Cerium による Task を用いた描画処理</li>
 	<li>Super Dandy のコードやデータ構造を流用</li>
     </ul></td>
     <td>
@@ -252,6 +255,7 @@
 </table>
 </div>
 
+<!--
 <div class="slide">
 <h1>目標とするテスト環境</h1>
 <ul class="simple">
@@ -260,10 +264,11 @@
   <li>高速なテスト環境</li>
 </ul>
 </div>
+-->
 
 <div class="slide">
 <h1>並列処理によるバグ</h1>
-<table>
+<font size="3"><table>
   <tr>
     <td><ul class="simple">
 	<li>逐次処理と異なり、並列処理では、敵オブジェクトの処理が弾の動く処理より先に行われる場合がある</li>
@@ -287,11 +292,11 @@
     </td>
   </tr>
 
-</table>
+</table></font>
+</div>
 
 <!--
 <font size="3"><ul class="simple">
-
   <li>逐次処理では弾の動く処理の後、敵オブジェクトが動く</li>
   <li>敵オブジェクトが動く前に被弾したため、敵オブジェクトは削除される</li>
   <li>逐次処理と異なり、並列処理では、敵オブジェクトの処理が弾の動く処理より先に行われる場合がある</li>
@@ -302,6 +307,7 @@
 <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>
@@ -405,6 +411,7 @@
 </table>
 </div>
 
+<!--
 <div class="slide">
 <h1>テスト環境における描画処理</h1>
 <table>
@@ -420,6 +427,7 @@
   </tr>
 </table>
 </div>
+-->
 
 <div class="slide">
 <h1>バグの検出方法</h1>
@@ -555,11 +563,13 @@
 -->
 
 <div class="slide">
-<h1>ビデオモードによる実行時間の比較</h1>
-<p>SuperDandy と TaskDandy の描画の有無による実行時間を観測</p>
+<h1>描画の有無による実行時間の比較</h1>
+<font size="4">
+<h2>プレイヤー入力の固定化により描画処理を省略することができる</h2>
+</font>
 <center>
 <table border="1" cellspacing="0">
-  <tr><td></td><!--<th>SuperDandy</th>--><th>TaskDandy</th><th>TaskDandy(no video)</th></tr>
+  <tr><td></td><!--<th>SuperDandy</th>--><th>描画有り</th><th>描画無し</th></tr>
   <tr><th>実行時間</th><!--<td>336.09 sec</td>--><td>6643.16 sec</td><td>385.17 sec</td></tr>
 </table>
 </center>
@@ -577,11 +587,11 @@
 <h1>まとめ</h1>
 <!--<h2>本研究では並列環境におけるゲームプログラムのテスト手法を提案した</h2>-->
 <ul class="simple">
+  <li>ゲームにおけるランダム要素であるプレイヤー入力、乱数生成を固定化した</li>
   <li>ゲームの状態遷移時におけるバグの検出を行った</li>
-  <li>ゲームにおけるランダム要素であるプレイヤー入力、乱数生成を固定化した</li>
   <li>描画の除去によるテストの高速化を行った</li>
   <br>
-  <li>ゲームの状態遷移数を数えることにより、ゲーム内の全ての事象をテストできる</li>
+  <li>ゲームの状態遷移数を数えることにより、ゲーム内の全ての状態をテストできる</li>
   <li>並列環境上における、ゲームプログラムのテストを自動化する事が可能</li>
   <li>今後はゲームの状態遷移数の数え上げを行う</li>
 </ul>