Mercurial > hg > Papers > 2011 > koba-master

comparison presen/master-presen.html @ 15:eda303b6b20f

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
add presen and poster directory.
author koba <koba@cr.ie.u-ryukyu.ac.jp>
date Tue, 15 Feb 2011 18:06:15 +0900
parents
children c20d7b72cd4a
comparison
equal deleted inserted replaced
14:19be75493fbb 15:eda303b6b20f
1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
2 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
3
4 <html xmlns="http://www.w3.org/1999/xhtml">
5
6 <head>
7 <title>master_presentation</title>
8 <!-- metadata -->
9 <meta name="generator" content="S5" />
10 <meta name="version" content="S5 1.1" />
11 <meta name="presdate" content="20050728" />
12 <meta name="author" content="Eric A. Meyer" />
13 <meta name="company" content="Complex Spiral Consulting" />
14 <!-- configuration parameters -->
15 <meta name="defaultView" content="slideshow" />
16 <meta name="controlVis" content="hidden" />
17 <!-- style sheet links -->
18 <link rel="stylesheet" href="ui/default/slides.css" type="text/css" media="projection" id="slideProj" />
19 <link rel="stylesheet" href="ui/default/outline.css" type="text/css" media="screen" id="outlineStyle" />
20 <link rel="stylesheet" href="ui/default/print.css" type="text/css" media="print" id="slidePrint" />
21 <link rel="stylesheet" href="ui/default/opera.css" type="text/css" media="projection" id="operaFix" />
22 <!-- S5 JS -->
23 <script src="ui/default/slides.js" type="text/javascript"></script>
24 </head>
25 <body>
26
27 <div class="layout">
28 <div id="controls"><!-- DO NOT EDIT --></div>
29 <div id="currentSlide"><!-- DO NOT EDIT --></div>
30 <div id="header"></div>
31 <div id="footer">
32 <h1>[date:11/02/09]</h1>
33 <h2>Game Framework Cerium を用いたゲームプログラミングにおけるテスト手法の提案</h2>
34 </div>
35
36 </div>
37
38
39 <div class="presentation">
40
41 <div class="slide">
42 <h1>Game Framework Cerium を用いた<br>
43 ゲームプログラミングにおける<br>
44 テスト手法の提案</h1>
45 <h3>発表者:小林　佑亮</h3>
46 <h4>所属:琉球大学 理工学研究科 情報工学専攻 並列信頼研究室</h4>
47 <h4>指導教員:河野　真治</h4>
48 </div>
49
50 <div class="slide">
51 <h1>発表内容</h1>
52 <ol>
53 <li>序論</li>
54 <li>CppUnit を用いたゲームプログラムテスト</li>
55 <li>ゲームプログラミングにおけるテスト</li>
56 <li>Cell BE と Cerium</li>
57 <li>テスト対象のシューティングゲーム Super Dandy</li>
58 <li>構築したテスト環境</li>
59 <li>テスト環境によるデバッグと検証</li>
60 <li>まとめ</li>
61 </ol>
62 </div>
63
64 <div class="slide">
65 <h1>研究背景</h1>
66 <font size="4"><ul>
67 <li>我々は PlayStation3(以下 PS3) 上においてゲーム開発が行えるフレームワーク
68 Cerium を開発した。</li>
69 <li>Cerium ではプログラムを Task という単位に分けて管理し、これを PS3 の
70 アーキテクチャである Cell B.E に渡して並列処理を行う。</li>
71 <li>シーケンシャルなプログラムを Task に分割して並列実行させても、
72 逐次実行させた時と同じ動作をするとは限らない。</li>
73 <li>オブジェクト同士のデータの同期や、処理の実行順序など、シーケンシャルな
74 プログラムに比べて、バグを発生させる要因は多い。</li>
75 <li>また、ゲームプログラムの特徴はプレイヤーの入力やプログラム内にある乱数
76 などの非決定的な要素が多いことが挙げられる。</li>
77 <li>これによってバグの再現性が低下するため、ゲームプログラムのテストは
78 一般的なソフトウェアのテストに比べて難しい</li>
79 </ul></font>
80 </div>
81
82 <div class="slide">
83 <h1>研究目的</h1>
84 <font size="4"><ul>
85 <li>本研究では Task に分割されたゲームプログラムがシーケンシャルなバージョン
86 と同じ動作である事を確認できるテスト環境の構築を目的とする。</li>
87 <li>プレイヤーの入力や乱数などの非決定的な要素を固定化し、バグの再現性を
88 低下させずにテストを行えるようにする。</li>
89 <li>動作の同一性を確かめるために必要なパラメータの書き出しを行う</li>
90 <li>高速なテストを行う為、テストに影響しない範囲で実行時間が大きい処理を
91 排除する。</li>
92 </ul></font>
93 </div>
94
95 <div class="slide">
96 <h1>CppUnit</h1>
97 <ul class="simple">
98 <li>xUnit と呼ばれる単体テストのためのフレームワークの内の 1 つ</li>
99 <li>単体テストとは関数やメソッドなどの比較的小さな単位で行うテストで、
100 モジュールへの入力と出力を調べることでそのモジュールが要求された仕様を
101 満たしているかをテストする手法</li>
102 <li>CppUnit は 1 つの事象に対して様々なテストケースを同時にテストできる</li>
103 <li>羅列したテストケースは一括で実行と結果表示が出来る</li>
104 <li>しかしこうした単体テストではゲームプログラムのバグを見つけるのは難しい</li>
105 </ul>
106 </div>
107
108 <div class="slide">
109 <h1>ゲームオブジェクトに対するテスト</h1>
110 <table>
111 <tr>
112 <td><ul class="simple">
113 <li>3 つの SceneGraph ノードを持つ</li>
114 <li>本体を tree の root として左右のパーツがその子供になっている。</li>
115 <li>オブジェクトの動き(Move)として左右の平行移動をする</li>
116 <li>簡単なゲームの例題</li>
117 </ul></td>
118 <td><img src="images/boss1_SG.png" width=300 height=250></td>
119 </tr>
120 </table>
121 </div>
122
123 <div class="slide">
124 <h1>ゲームオブジェクトに対するテスト</h1>
125 <h2>テスト方法</h2>
126 <ul class="simple">
127 <li>SceneGraph tree の root のアドレスを取得</li>
128 <li>そこから tree を辿って各オブジェクトの座標を取得</li>
129 <li>初期値を入力してオブジェクトの初期化が正しいか調べる</li>
130 </ul>
131 <h2>テスト結果</h2>
132 <ul class="simple">
133 <li>全てのオブジェクトの初期値が正しい事がわかった</li>
134 <li>初期化の段階でバグが発生していないことが保証された</li>
135 </ul>
136 </div>
137
138 <div class="slide">
139 <h1>ゲームに対する単体テストの欠点</h1>
140 <ul>
141 <li>単体テストは瞬間的な値の正しさは調べられる</li>
142 <li>常にオブジェクトのパラメータが変化するゲームには有効的ではない</li>
143 <li>ゲームのバグは他のオブジェクトのパラメータとの関係により発生するものが
144 多い</li>
145 <li>一般的な単体テストではゲームのバグの発見は難しい</li>
146 </ul>
147 </div>
148
149 <div class="slide">
150 <h1>ゲームプログラムの特徴</h1>
151 <table>
152 <tr>
153 <td><ul class="simple">
154 <li>多数のオブジェクトが存在する</li>
155 <li>オブジェクト同士が相互に干渉する</li>
156 <li>プレイヤーの入力やゲームの進行によって新たなオブジェクトが生成される</li>
157 <li>オブジェクトは他のオブジェクトのパラメータを見て、衝突判定や挙動の変化をする</li>
158 </ul></td>
159 <td>
160 <img src="images/game.png" width=300 height=250/>
161 </td>
162 </tr>
163 </table>
164 </div>
165
166 <div class="slide">
167 <h1>ゲームプログラムの特徴</h1>
168 <ul class="simple">
169 <li>プレイヤーの入力がゲームに影響する</li>
170 <li>遷移する状態が膨大</li>
171 <li>遷移する状態が仕様の範囲内に収まるかをチェックするテストは向かない</li>
172 <li>実際にプレイヤーがゲームをプレイするのが重要なテスト</li>
173 </ul>
174 </div>
175
176 <div class="slide">
177 <h1>プレイヤーの入力の不定性</h1>
178 <ul class="simple">
179 <li>プレイヤーの入力は常に非決定的(毎回結果が異なる)</li>
180 <li>同じ人間が同じゲームの同じ場面をプレイしても全く同じ入力をする可能性
181 は極めて低い</li>
182 <li>プレイヤーは制御不能なランダム要素</li>
183 <li>テストにおけるバグの再現性を低下させている</li>
184 </ul>
185 </div>
186
187 <div class="slide">
188 <h1>ゲームにおける乱数の役割</h1>
189 <ul class="simple">
190 <li>オブジェクトの振る舞いに多様性を持たせる</li>
191 <li>ランダムな位置配置に使われる</li>
192 <li>乱数のランダム性はデバッグをする上でバグの再現を困難にする</li>
193 <li>対処法としては、乱数生成器を無効にするか、定数でシードする</li>
194 </ul>
195 </div>
196
197 <div class="slide">
198 <h1>Cell Broadband Engine</h1>
199 <ul class="simple">
200 <li>SCE と 東芝、IBM によって開発されたCPU</li>
201 <li>2 thread の PPE(PowerPC Processor Element) と 8 個の
202 SPE(Synergistic Processor Element)を持つ</li>
203 <li>各 CPU 間は高速リングバスであるEIB(Element Interface Bus)で
204 繋がっている</li>
205 </ul>
206 <center>
207 <img src="images/cell.png" width=350 height=150/>
208 </center>
209 </div>
210
211 <div class="slide">
212 <h1>Game Framework Cerium</h1>
213 <dl>
214 <b><dt>SceneGraph</dt></b>
215 <dd>オブジェクトのパラメータやポリゴン情報を tree 構造のノードで管理</dd>
216 <b><dt>Rendering Engine</dt></b>
217 <dd>3 種類の Task によって並列に描画処理を行う</dd>
218 <b><dt>TaskManager</dt></b>
219 <dd>Task を動的に SPE へ割り振るカーネルとして振舞う</dd>
220 </dl>
221 </div>
222
223 <div class="slide">
224 <h1>Task Manager</h1>
225 <ul class="simple">
226 <li>Task と呼ばれる分割されたプログラムを管理する</li>
227 <li>Task の単位はサブルーチンまたは関数とする。</li>
228 <li>生成された Task を依存関係を考慮しながら SPE に転送したり、実行する</li>
229 </ul>
230 </div>
231
232 <div class="slide">
233 <h1>Task 生成時に使用できる API</h1>
234 <center>
235 <table border="1" cellspacing="0">
236 <tr><th>create_task</th><td>Task を生成する</td>
237 <tr><th>set_inData</th><td>Task への入力データのアドレスを追加</td>
238 <tr><th>set_outData</th><td>Task からの出力先アドレスを追加</td>
239 <tr><th>set_param</th><td>Task に 32 bit の情報を追加</td>
240 <tr><th>set_post</th><td>Task が終了した後に PPE 側で実行される関数を登録</td>
241 </table>
242 </center>
243 </div>
244
245 <div class="slide">
246 <h1>シューティングゲーム SuperDandy</h1>
247 <table>
248 <tr>
249 <td><ul class="simple">
250 <li>我々が PlayStation 上でのゲーム開発を行っていた 1998 年に開発</li>
251 <li>タイトルからゲーム本編中の敵機の登場、ステージクリア、エンディングと
252 ゲーム的な要素が多い</li>
253 <li>PlayStation, PlayStation2 Linux, OpenGL と伝統的に移植されてきた</li>
254 </ul></td>
255 <td>
256 <img src="images/dandy.png" width=300 height=250/>
257 </td>
258 </tr>
259 </table>
260 </div>
261
262 <div class="slide">
263 <h1>Super Dandy 移植の利点</h1>
264 <ul class="simple">
265 <li>全 5 ステージという、ある程度のボリュームのあるゲーム</li>
266 <li>衝突判定やオブジェクト判定、ステージクリアによるシーン切り替えと、基本的なゲームの要素が入っている</li>
267 <li>動作結果を過去の環境と比較することによる新たな環境のチューニングができる</li>
268 </ul>
269 </div>
270
271 <div class="slide">
272 <h1>Super Dandy Cerium version</h1>
273 <ul class="simple">
274 <li>最初に Cerium に対応したバージョン</li>
275 <li>描画処理に Cerium の Rendering Engine を用いており、その箇所のみ
276 Task で処理される</li>
277 <li>基本的なゲームの処理は変わらない</li>
278 </ul>
279 </div>
280
281 <div class="slide">
282 <h1>Task Dandy(Super Dandy Task version)</h1>
283 <table>
284 <tr>
285 <td><ul class="simple">
286 <li>オブジェクトの Move や Collision を Task 化</li>
287 <li>オブジェクトの描画は SceneGraph tree の形成、Rendering Task の
288 生成といった Cerium の描画処理を使用</li>
289 <li>できるだけ Super Dandy のコードやデータ構造を流用</li>
290 </ul></td>
291 <td>
292 <img src="images/taskdandy.png" width=300 height=300/>
293 </td>
294 </tr>
295 </table>
296 </div>
297
298 <div class="slide">
299 <h1>Task Dandy のデータ構造</h1>
300 <dl>
301 <b><dt>player</dt></b>
302 <dd>プレイヤーの操作する機体。xy 座標、残機数、無敵時間、
303 コンテニュー回数などを持つ。</dd>
304 <b><dt>CHARACTER</dt></b>
305 <dd>敵機や敵の弾。xy 座標とその方向の速さ、体力、倒したときのスコア、
306 オブジェクトの種類を表すキャラナンバーを持つ。</dd>
307 <b><dt>tama_lv1〜lv3、laser_lv1〜lv3</dt></b>
308 <dd>プレイヤーが撃った弾。xy 座標をもつ。プレイヤーが射撃ボタンを押すと
309 弾が配列に格納され、敵に当たるか画面外にいくと消滅する。</dd>
310 </dl>
311 </div>
312
313 <div class="slide">
314 <h1>データ転送に用いる Property</h1>
315 <table>
316 <tr>
317 <td><ul class="simple">
318 <li>必要なパラメータをまとめて Property にコピーして set_inData</li>
319 <li>複数のデータをまとめることによって Task の inData を簡略化</li>
320 </ul></td>
321 <td>
322 <img src="images/property.png" width=400 height=300/>
323 </td>
324 </tr>
325 </table>
326 </div>
327
328 <div class="slide">
329 <h1>ステートパターン</h1>
330 <table>
331 <tr>
332 <td><font size="4"><ul class="simple">
333 <li>オブジェクトの Move と Collision を行う</li>
334 <li>オブジェクトが関数ポインタを持ち、そのポインタが示す関数が
335 Move や Collision の処理を行う</li>
336 <li>関数ポインタのアドレスを他の関数ポインタのアドレスに書き換え、
337 オブジェクトの状態遷移をする</li>
338 <li>しかし、メモリが独立している SPE 上で状態遷移をする場合、
339 ステートパターンで使用した関数ポインタのアドレスは使えない</li>
340 </ul></font></td>
341 <td>
342 <img src="images/state_pattern.png" width=300 height=200/>
343 </td>
344 </tr>
345 </table>
346 </div>
347
348 <div class="slide">
349 <h1>SPE における状態遷移</h1>
350 <table>
351 <tr>
352 <td><ul class="simple">
353 <li>SPE 上では Task の ID を変更</li>
354 <li>PPE 上で変更された ID を見て次に生成する Task の種類を変更</li>
355 <li>オブジェクトの状態遷移が成立</li>
356 </ul></td>
357 <td>
358 <img src="images/task_change.png" width=400 height=300/>
359 </td>
360 </tr>
361 </table>
362 </div>
363
364 <div class="slide">
365 <h1>目標とするテスト環境</h1>
366 <ul class="simple">
367 <li>プレイヤーの入力や乱数などの非決定的な要素の固定化</li>
368 <li>現在動作中の OpenGL バージョンと Cerium バージョン、そして Task Dandy
369 の動作が同一かどうか確認できるテストログの出力</li>
370 <li>高速なテスト環境</li>
371 </ul>
372 </div>
373
374 <div class="slide">
375 <h1>Capture モードと Trace モード</h1>
376 <ul class="simple">
377 <li>プレイヤーからの入力を 1 フレーム毎に記録する</li>
378 <li>記録した入力をバイナリデータとして書き出す</li>
379 <li>書き出したファイルを読み込むことで過去のプレイヤー入力を再現できる</li>
380 <li>実行ファイルにオプションとファイル名を付けて起動する</li>
381 <li>3 つの Super Dandy 全てで使える</li>
382 <li>旧バージョンの入力を記録し、新バージョンで読み出すことができる</li>
383 <li>入力が同じでも動作が違えばそこにバグが潜んでいると考えられる</li>
384 </ul>
385 </div>
386
387 <div class="slide">
388 <h1>入力を記録するバッファのデータ構造</h1>
389 <ul class="simple">
390 <li>単方向リスト型のバッファ</li>
391 <li>Capture モードではバッファが足りなくなると新たなバッファを確保する</li>
392 <li>Trace モードでは必要なバッファサイズを計算し、あらかじめバッファを確保しておく</li>
393 </ul>
394 <center>
395 <img src="images/pad_buff.png" width=400 height=150>
396 </center>
397 </div>
398
399 <div class="slide">
400 <h1>SPE における乱数生成</h1>
401 <font size="4"><ul class="simple">
402 <li>シーケンシャルプログラムでは 1 つの乱数列から順番に乱数を取得</li>
403 <li>Cell における並列プログラムでは各 SPE 内で 独自の乱数列を生成</li>
404 <li>SPE に送られた Task は SPE 固有の乱数列を使用</li>
405 <li>SPE 内では依存関係を持たない Task は実行順序が不定</li>
406 <li>シーケンシャルと並列で異なる結果が出る</li>
407 </ul></font>
408 <center>
409 <img src="images/spe_random.png" width=400 height=150>
410 </center>
411 </div>
412
413 <div class="slide">
414 <h1>SPE 内での予測可能な乱数の使用</h1>
415 <table>
416 <tr>
417 <td><ul class="simple">
418 <li>あらかじめ PPE 内で乱数列を生成しておく</li>
419 <li>inData として Task に渡す</li>
420 <li>Move Task や Collision Task の生成タイミングは Super Dandy の
421 Move や Collision のタイミングと同じ</li>
422 <li>Super Dandy と同じ乱数が使用できる</li>
423 </ul></td>
424 <td>
425 <img src="images/ppe_random.png" width=400 height=300/>
426 </td>
427 </tr>
428 </table>
429 </div>
430
431 <div class="slide">
432 <h1>並列処理をすることによって発生するバグ</h1>
433 <table>
434 <tr>
435 <td><ul>
436 <li>Task 間のデータの同期による衝突判定のバグ</li>
437 <li>Task の実行順序の違いによる衝突判定のバグ</li>
438 <li>Task の実装の違い</li>
439 <li>主にオブジェクトの衝突判定でバグが発生</li>
440 <li>衝突時のログを見ることでバグを発見する</li>
441 </ul></td>
442 <td>
443 <img src="images/test_log.png" width=350 height=300/>
444 </td>
445 </tr>
446 </table>
447 </div>
448
449 <div class="slide">
450 <h1>出力されるテストログ</h1>
451 <font size="4"><pre>
452 F64: CREATE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -128.000000
453 vx= 0.000000 vy= 4.000000
454 F85: DELETE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -44.000000
455 vx= 0.000000 vy= 4.000000
456 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
457 </pre></font>
458 <dl class="simple">
459 <b><dt>F64, F85</dt></b>
460 <dd>生成、被弾した時の経過フレーム</dd>
461 <b><dt>CREATE, DELETE</dt></b>
462 <dd>CREATE はオブジェクトの生成、DELETE はオブジェクトの被弾</dd>
463 <b><dt>NAME</dt></b>
464 <dd>オブジェクトの種類と ID</dd>
465 <dl>
466 </div>
467
468 <div class="slide">
469 <h1>出力されるテストログ</h1>
470 <font size="4"><pre>
471 F64: CREATE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -128.000000
472 vx= 0.000000 vy= 4.000000
473 F85: DELETE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -44.000000
474 vx= 0.000000 vy= 4.000000
475 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
476 </pre></font>
477 <dl>
478 <b><dt>COORD</dt></b>
479 <dd>オブジェクトの xy 座標と速度</dd>
480 <b><dt>BULLET</dt></b>
481 <dd>その瞬間に画面内に存在した弾丸の数。</dd>
482 </dl>
483 </div>
484
485 <div class="slide">
486 <h1>Cerium における画面の描画処理</h1>
487 <table>
488 <tr>
489 <td><ul class="simple">
490 <li>ビデオモードの選択(SDL, OpenGL)</li>
491 <li>描画処理を行う画面バッファの領域の確保</li>
492 <li>ゲーム処理の実行</li>
493 <li>レンダリング Task による画面バッファへの描画</li>
494 </ul></td>
495 <td>
496 <img src="images/video.png" width=300 height=300/>
497 </td>
498 </tr>
499 </table>
500 </div>
501
502 <div class="slide">
503 <h1>本研究のテスト環境における描画処理</h1>
504 <table>
505 <tr>
506 <td><ul class="simple">
507 <li>プレイヤーの入力の自動化により、プログラムを実行するだけでテストが可能</li>
508 <li>描画処理が不要となる</li>
509 <li>描画用 Task の生成を行わない事により、テストの高速化ができる</li>
510 <li>また、画面バッファの確保も不要</li>
511 </ul></td>
512 <td>
513 <img src="images/video2.png" width=300 height=300/>
514 </td>
515 </tr>
516 </table>
517 </div>
518
519 <div class="slide">
520 <h1>描画処理を行わないモード</h1>
521 <ul class="simple">
522 <li>ビデオモードの選択時に選ぶ</li>
523 <li>Task を生成する処理をスルーしてゲーム処理を実行</li>
524 </ul>
525 <center>
526 <img src="images/video_none.png" width=200 height=150/>
527 </center>
528 </div>
529
530 <div class="slide">
531 <h1>本研究のテスト環境におけるバグの検出方法</h1>
532 <ul class="simple">
533 <li>OpenGL バージョンを Capture モードでプレイし、入力を記録</li>
534 <li>Cerium バージョン、Task Dandy を Trace モードで実行</li>
535 <li>各バージョンで得られたテストログを比較、考察</li>
536 <li>テストログの違いにより、バグの発生している箇所を特定</li>
537 </ul>
538 </div>
539
540 <div class="slide">
541 <h1>OpenGL と Cerium のテストログの比較</h1>
542 <center>
543 <table border="1" cellspacing="0">
544 <tr><td></td><th>大きさ</th><th>行数</th><th>単語数</th></tr>
545 <tr><th>OpenGL</th><td>349486 byte</td><td>3411</td><td>37194</td></tr>
546 <tr><th>Cerium</th><td>349471 byte</td><td>3411</td><td>37195</td></tr>
547 </table>
548 </center>
549 <ul class="simple">
550 <li>Cerium バージョンは描画を行わないモードで実行</li>
551 <li>エンディングまでプレイした入力データを仕様</li>
552 <li>テストログのデータに unix コマンドの wc(word count) コマンドを実行して検証</li>
553 <li>各バージョンで得られたテストログを比較、考察</li>
554 </ul>
555 </div>
556
557 <div class="slide">
558 <h1>OpenGL と Cerium のテストログの比較</h1>
559 <center>
560 <table border="1" cellspacing="0">
561 <tr><td></td><th>大きさ</th><th>行数</th><th>単語数</th></tr>
562 <tr><th>OpenGL</th><td>349486 byte</td><td>3411</td><td>37194</td></tr>
563 <tr><th>Cerium</th><td>349471 byte</td><td>3411</td><td>37195</td></tr>
564 </table>
565 </center>
566 <ul class="simple">
567 <li>2 つのログに大きな差は無い</li>
568 <li>Super Dandy をエンディングまでプレイしたときに得られるテストログの大きさ
569 は約 350 KB</li>
570 <li>単語数と大きさに僅かな差</li>
571 </ul>
572 </div>
573
574 <div class="slide">
575 <h1>diff によるテストログの比較</h1>
576 <font size="4"><pre>
577 % diff log/demo_log log/dandy_log
578 1a2
579 > Use Joystick
580 3410,3411c3411,3412
581 < 83.308451 FPS
582 < move: average:49usec, peak:1091usec
583 ---
584 > 0.000000 FPS
585 > game end
586 </pre></font>
587 <ul class="simple">
588 <li>表示されているメッセージは OpenGL や Cerium 依存のメッセージ</li>
589 <li>0.000000 FPS は Cerium 側のメッセージで描画を行わないビデオモードにより
590 正しく FPS の計算ができなかったため</li>
591 <li>wc の単語数はスペース区切りで判別するため、Cerium=6,OpenGL=5</li>
592 <li>よって両バージョンの動作は同じである</li>
593 </ul>
594 </div>
595
596 <div class="slide">
597 <h1>OpenGL バージョンと Task Dandy の比較</h1>
598 <font size="4"><pre>
599 super dandy(OpenGL) >>
600 F64: CREATE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -128.000000 ...
601 F85: DELETE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -44.000000 ...
602 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
603 F96: CREATE [NAME]enemy_greenclab_1 [COORD]x= 56.000000 y= -128.000000 ...
604 F96: CREATE [NAME]enemy_greenclab_2 [COORD]x= 184.000000 y= -128.000000 ...
605 F109: DELETE [NAME]enemy_greenclab_1 [COORD]x= 56.000000 y= -24.000000 ...
606 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
607 F117: DELETE [NAME]enemy_greenclab_2 [COORD]x= 184.000000 y= 40.000000 ...
608 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
609
610 << task dandy
611 F64: CREATE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -128.000000 ...
612 F85: DELETE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -44.000000 ...
613 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
614 F96: CREATE [NAME]enemy_greenclab_1 [COORD]x= 56.000000 y= -128.000000 ...
615 F96: CREATE [NAME]enemy_greenclab_2 [COORD]x= 184.000000 y= -128.000000 ...
616 F109: DELETE [NAME]enemy_greenclab_1 [COORD]x= 56.000000 y= -24.000000 ...
617 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
618 F109: DELETE [NAME]enemy_greenclab_2 [COORD]x= 184.000000 y= -24.000000 ...
619 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
620 </pre></font>
621 </div>
622
623 <div class="slide">
624 <h1>ログからのバグの洗い出し</h1>
625 <font size="4"><pre>
626 super dandy(OpenGL) >>
627 F109: DELETE [NAME]enemy_greenclab_1 [COORD]x= 56.000000 y= -24.000000 ...
628 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
629 F117: DELETE [NAME]enemy_greenclab_2 [COORD]x= 184.000000 y= 40.000000 ...
630 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
631
632 << task dandy
633 F109: DELETE [NAME]enemy_greenclab_1 [COORD]x= 56.000000 y= -24.000000 ...
634 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
635 F109: DELETE [NAME]enemy_greenclab_2 [COORD]x= 184.000000 y= -24.000000 ...
636 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
637 </pre></font>
638 <ul class="simple">
639 <li>OpenGL では別フレームで死んだ 2 つの敵オブジェクトが Task Dandy では
640 同フレームで死亡</li>
641 <li>この時の弾丸の数が一致</li>
642 <li>片方が死んだ後、弾丸のオブジェクトの除去がされてない</li>
643 <li>弾丸データが取れていない、という仮説を立てた</li>
644 </ul>
645 </div>
646
647 <div class="slide">
648 <h1>Collision Task 間でのデータの同期</h1>
649 <table>
650 <tr>
651 <td><ul class="simple">
652 <li>Collision Task を同じ CPU に送る</li>
653 <li>予め衝突判定に必要なパラメータの領域を確保する</li>
654 <li>その領域のパラメータで衝突判定を行う</li>
655 <li>SPE 内で変更されたパラメータをメインメモリ側に反映させる</li>
656 </ul></td>
657 <td>
658 <img src="images/collision_reflect.png" width=300 height=300/>
659 </td>
660 </tr>
661 </table>
662 </div>
663
664 <div class="slide">
665 <h1>Collision Task の改良後の比較</h1>
666 <font size="4"><pre>
667 super dandy>>
668 F64: CREATE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -128.000000 ...
669 F85: DELETE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -44.000000 ...
670 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
671 F96: CREATE [NAME]enemy_greenclab_1 [COORD]x= 56.000000 y= -128.000000 ...
672 F96: CREATE [NAME]enemy_greenclab_2 [COORD]x= 184.000000 y= -128.000000 ...
673 F109: DELETE [NAME]enemy_greenclab_1 [COORD]x= 56.000000 y= -24.000000 ...
674 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
675 F117: DELETE [NAME]enemy_greenclab_2 [COORD]x= 184.000000 y= 40.000000 ...
676 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
677
678 << task dandy
679 F64: CREATE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -128.000000 ...
680 F85: DELETE [NAME]enemy_greenclab_0 [COORD]x= 120.000000 y= -44.000000 ...
681 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
682 F96: CREATE [NAME]enemy_greenclab_1 [COORD]x= 56.000000 y= -128.000000 ...
683 F96: CREATE [NAME]enemy_greenclab_2 [COORD]x= 184.000000 y= -128.000000 ...
684 F109: DELETE [NAME]enemy_greenclab_1 [COORD]x= 56.000000 y= -24.000000 ...
685 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
686 F117: DELETE [NAME]enemy_greenclab_2 [COORD]x= 184.000000 y= 40.000000 ...
687 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
688 </pre></font>
689 </div>
690
691 <div class="slide">
692 <h1>Collision Task の改良後の比較</h1>
693 <font size="4"><pre>
694 super dandy(OpenGL) >>
695 F109: DELETE [NAME]enemy_greenclab_1 [COORD]x= 56.000000 y= -24.000000 ...
696 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
697 F117: DELETE [NAME]enemy_greenclab_2 [COORD]x= 184.000000 y= 40.000000 ...
698 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
699
700 << task dandy
701 F109: DELETE [NAME]enemy_greenclab_1 [COORD]x= 56.000000 y= -24.000000 ...
702 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
703 F117: DELETE [NAME]enemy_greenclab_2 [COORD]x= 184.000000 y= 40.000000 ...
704 [BULLET]tlv1 = 2, tlv2 = 0 llv1 = 0
705 </pre></font>
706 <ul class="simple">
707 <li>2 つのバージョンのログがフレーム単位で同じ</li>
708 <li>Collision Task のデータ同期が有効に働いている</li>
709 </ul>
710 </div>
711
712 <div class="slide">
713 <h1>Task への乱数受け渡しの検証</h1>
714 <ul class="simple">
715 <li>多数の隕石オブジェクトが生成されるステージで全ての隕石オブジェクトが
716 生成されるのを観察</li>
717 <li>隕石オブジェクトの初期配置は乱数によるランダム配置</li>
718 <li>隕石オブジェクト生成後の座標と速度を出力</li>
719 </ul>
720 </div>
721
722 <div class="slide">
723 <h1>隕石オブジェクトの実装</h1>
724 <font size="4"><pre>
725 int sf;
726
727 sf = random() % 4;
728 if((sf == 0) || (sf == 1))
729 {
730 p->x = -35;
731 p->y = random() % (120 - 35);
732 p->vx = (random() % 4 + 1);
733 p->vy = random() % 3 + 1;
734 p->state = chara_state23;
735 }
736 if((sf == 2))
737 {
738 p->x = random() % 290;
739 p->y = -30;
740 p->vx = random() % 3 - 1;
741 p->vy = (random() % 4 + 1);
742 p->state = chara_state23;
743 }
744 if(sf == 3)
745 {
746 .....
747 </pre></font>
748 </div>
749
750 <div class="slide">
751 <h1>Task Dandy 側の実装</h1>
752 <font size="4"><pre>
753 int rand1 = (int)smanager->get_param(0);
754 int rand2 = (int)smanager->get_param(1);
755 int rand3 = (int)smanager->get_param(2);
756 int rand4 = (int)smanager->get_param(3);
757
758 CHARACTER *p = (CHARACTER*)smanager->get_input(rbuf, 0);
759
760 int sf = rand1 % 4;
761 if((sf == 0) || (sf == 1))
762 {
763 p->x = -35;
764 p->y = rand2 % (120 - 35);
765 p->vx = (rand3 % 4 + 1);
766 p->vy = rand4 % 3 + 1;
767 }
768 if((sf == 2))
769 {
770 p->x = rand2 % 290;
771 p->y = -30;
772 p->vx = rand3 % 3 - 1;
773 p->vy = (rand4 % 4 + 1);
774 .....
775 </pre></font>
776 </div>
777
778 <div class="slide">
779 <h1>実行結果</h1>
780 <font size="4"><pre>
781 demolog >>
782 [COORD]x= 320.000000 y= 66.000000 vx= -2.000000 vy= 0.000000
783 [COORD]x= -35.000000 y= 20.000000 vx= 3.000000 vy= 1.000000
784 [COORD]x= -35.000000 y= 36.000000 vx= 3.000000 vy= 2.000000
785 [COORD]x= 89.000000 y= -30.000000 vx= 1.000000 vy= 3.000000
786 [COORD]x= -35.000000 y= 81.000000 vx= 1.000000 vy= 2.000000
787 [COORD]x= 320.000000 y= 8.000000 vx= -4.000000 vy= -1.000000
788 [COORD]x= 220.000000 y= -30.000000 vx= 1.000000 vy= 4.000000
789 ....
790
791 << tdandylog
792 [COORD]x= 320.000000 y= 66.000000 vx= -2.000000 vy= 0.000000
793 [COORD]x= -35.000000 y= 20.000000 vx= 3.000000 vy= 1.000000
794 [COORD]x= -35.000000 y= 36.000000 vx= 3.000000 vy= 2.000000
795 [COORD]x= 89.000000 y= -30.000000 vx= 1.000000 vy= 3.000000
796 [COORD]x= -35.000000 y= 81.000000 vx= 1.000000 vy= 2.000000
797 [COORD]x= 320.000000 y= 8.000000 vx= -4.000000 vy= -1.000000
798 [COORD]x= 220.000000 y= -30.000000 vx= 1.000000 vy= 4.000000
799 ....
800
801 % diff demolog tdandylog
802 %
803 </pre></font>
804 </div>
805
806 <div class="slide">
807 <h1>乱数受け渡しによる実行結果の検証</h1>
808 <ul class="simple">
809 <li>生成された隕石オブジェクトのパラメータが両バージョンで一致している</li>
810 <li>Task への乱数受け渡しによるバグの再現性の低下防止は有効である</li>
811 </ul>
812 </div>
813
814 <div class="slide">
815 <h1>ビデオモードによる実行時間の比較</h1>
816 <ul class="simple">
817 <li>実行時間の計測には unix の time コマンドを使用</li>
818 <li>3 バージョンの描画無しモードを使用(OpenGL は 1x1)</li>
819 <li>描画ありバージョンは 1200x800 で統一して計測</li>
820 </ul>
821 </div>
822
823 <div class="slide">
824 <h1>実行結果</h1>
825 <table border="1" cellspacing="0">
826 <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>
827 <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>
828 </table>
829 <ul class="simple">
830 <li>OpenGL バージョンと Cerium バージョンではほとんど差がない</li>
831 <li>描画処理を除けば 2 つのバージョンには殆ど差がない為と考えられる</li>
832 <li>TaskDandy では Cerium における Task の処理が発生したため、実行時間が大きく増加したと考えられる</li>
833 </ul>
834 </div>
835
836 <div class="slide">
837 <h1>実行結果</h1>
838 <table border="1" cellspacing="0">
839 <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>
840 <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>
841 </table>
842 <ul class="simple">
843 <li>OpenGL では描画無しバージョンとの差がほとんど無い</li>
844 <li>Cerium バージョンや Task バージョンは劇的に処理時間が増加</li>
845 <li>描画処理の Task の処理時間が非常に大きいと考えられる</li>
846 <li>描画処理の Task に比べればゲームの Task は処理が小さい</li>
847 </ul>
848 </div>
849
850 <div class="slide">
851 <h1>結論</h1>
852 <h2>本研究では並列環境におけるゲームプログラムのテスト手法を提案した</h2>
853 <ul class="simple">
854 <li>衝突判定時のテストログ出力によるデバッグは OpenGL バージョンと Task
855 Dandy の実行結果が同じであることから、効果的であった</li>
856 <li>Task への乱数受け渡しによるバグの再現性は 同様にして有効であることが
857 わかった</li>
858 <li>描画をしないビデオモードによるテスト時間の高速化は、描画をする場合に
859 比べて 非常に効果があった</li>
860 </ul>
861 </div>
862
863 <div class="slide">
864 <h1>今後の課題</h1>
865 <ul class="simple">
866 <li>描画処理におけるバグの修正</li>
867 <li>Cerium におけるメモリアロケータの実装</li>
868 </ul>
869 </div>
870
871 </div>
872 </body>
873 </html>