\chapter{Cerium}
\section{Cerium}
我々は独自のレンダリングエンジンを持つことにした。そのレンダリングエンジンをCeriumとする。Ceriumは次の3つから構成される。\\
\begin{itemize}
\item シーングラフ
\item レンダリングエンジン
\item タスクマネージャ
\end{itemize}
シーングラフとレンダリングエンジンが結合して初めて画面上に描画が可能となり、その二つをタスクマネージャがSPU上で実行させる仕様となっている。
\subsection{シーングラフ}
ゲームの中の一つの場面(Scene)を構成するオブジェクトやその振る舞い、ゲームのルールの集合をSceneGraphとする。SceneGraphの各ノードがゲームの一部であるオブジェクトの振る舞いやゲームのルールとなり、ノードをたどり実行することでゲームの中の一つの場面となる。SceneGraphはゲームプログラムとしての条件を満たす物なので、一つのScene Graphで小さなゲームといえる。
\subsection{レンダリングエンジン}
レンダリングエンジンはOSMesaの機能を簡素化し、よりシンプルに使いやすく設計されたフレームワークである。OSMesaではいろいろな機能を付加し続けた結果、内部ではとても複雑な計算が行われている。また、マルチコアCPUに対応した
\subsection{タスクマネージャ}
タスクマネージャとはその名の通り、タスクを管理する物である。SPUは256kbという小さなデータ量しかもてない。そのため、なんどもSPUで違う動作をさせるためにはSPUのプログラムをロードしなければならない。プログラムのロードを逐次的に行うことも可能だがSPUのプログラムは必要なときに必要な実行プログラムがSPUにロードされていることが望ましい。そこで我々はSPURSの考えを基にタスクマネージャを作成した。\\
\section{Ceriumの実装}
\subsection{シーングラフ}
シーングラフはゲームのシーンを構成するオブジェクトやその振る舞いの記述である。シーングラフはxmlをパースするところか始まる。blenderから生成されるxmlは以下のような構造を持っている。\\
\input{src/cube-p.xml}
rotateや親子関係などを実装している。親子関係とは自転と公転のようなもので、例えば地球が自転すると、それに伴って月が公転するようなことである。それは子に対して親への変換行列がかけられている。それをスタック上に積んで計算する必要がある。(図\ref{fig:stack})\\
\begin{figure}[htb]
\begin{center}
\includegraphics{./fig/stack.eps}
\end{center}
\caption{親子関係のstack}
\label{fig:stack}
\end{figure}
親子関係などで計算されたポリゴンがレンダリングエンジンに渡される。しかし、それだけではなく、回転などの状態を残したアップデートされたポリゴンパックを保持して置く必要がある。
\subsection{レンダリングエンジン}
レンダリングエンジンは2つに分けることができる。spanを生成する部分と与えられたspanからテクスチャの生成する部分である。
\subsubsection{spanを生成する部分}
spanを生成するとき、シーングラフから必要な情報(polygonpack)が渡される。\\
\input{src/polygonpack.h}
polygonpackは光源の情報とテクスチャの情報と頂点の情報から構成される。TRIANGLEPACKというものがポリゴンに相当する物で、3つの頂点とそのポリゴンに対応するテクスチャの情報が格納されているアドレス、テクスチャの高さと幅が与えられている。３つの頂点にはx座標、y座標、z座標、テクスチャのx相対比、テクスチャのy相対比が与えられる。
この与えられたpolygonpackの情報からspanの情報を出力する。
\subsubsection{spanからテクスチャを計算する部分}
spanは次のような情報(spanpack)からテクスチャを計算し描画する。
\input{src/spanpack.h}
spanはテクスチャ情報のアドレスと高さと幅、それに加えてポリゴンのあるy座標に対するx、y、start\_z、tex\_x1、tex\_y1（左端のピクセル情報）とlength(spanの長さ)とend\_z、tex\_x2、tex\_y2（右端のピクセル情報)を持つ。(図\ref{fig:span})\\
\begin{figure}[htb]
\begin{center}
\includegraphics{./fig/span.eps}
\end{center}
\caption{span情報}
\label{fig:span}
\end{figure}
その情報からテクスチャを計算して、ピクセル毎のRGB$\alpha$情報を取得する
\subsection{タスクマネージャ}
タスクマネージャはオブジェクトファイルをタスクとして登録するだけであとは必要なときにSPUにロードしてくれる機能を持ったツールです。(図\ref{fig:load_obj})\\
\begin{figure}[htb]
\begin{center}
\includegraphics{./fig/load_object.eps}
\end{center}
\caption{load\_object}
\label{fig:load_obj}
\end{figure}
SPUでプログラムが終了すると勝手にSPUからそのオブジェクトファイルを追い出してくれます。
\section{開発手法}
\subsection{過去の移植行程}
我々はこれまでPlayStationで動作するプログラムのPlayStation2へ移植を行ってきた。移植はアーキテクチャーに依存するレイヤーとアーキテクチャーに依存しないレイヤーに分割し、依存レイヤーの部分のコードを書き換えてきた。（図\ref{fig:porting})しかし、それではアーキテクチャー依存間の差はとることは容易ではない。そこで我々がリファクタリングを用いて開発を行った。\\
ソフトウェアは一気に構成される訳ではなく、いくつかの変更を得て作られていく。新しい環境で使われるように変更すれば、再利用しやすくするために同じ動作をするプログラムを異なる構成に変更することもある。これらをリファクタリングと読んでいる。
\begin{figure}
\begin{center}
\includegraphics{./fig/porting.eps}
\end{center}
\caption{Adapterを用いたゲームプログラムの移植}
\label{fig:porting}
\end{figure}
\subsection{リファクタリングの詳細}
今回我々はOSMesaの高速化を実装したときにデバッグ環境がほとんどなく、とても苦労した。そこで我々は一度シーケンシャルなアルゴリズムで実装し、それをCellに移植するようにした。
シーケンシャルなアルゴリズムの実装では以下のようになる。
\input{src/overview-gameprogram.c}
これはSDLとSDL\_imageがインストールされている環境だとどこででも動作することができる。これらをいったん動作させ、正しく動かすことを確認する。その際、シーングラフの更新とSpanPackの生成、テクスチャーの生成などはSPUで動作することを前提としてプログラムを記述しなければならない。つまり、シーングラフの出力とSpanPackの生成の入力が同じになるように設計を行う。同様にSpanPackの生成の出力とテクスチャの生成の入力が同じにならなければならない。そうすることにより、よりCell上への移行がよりスムーズになる。