\chapter{開発行程}
\section{過去の移植行程}
我々はこれまでPlayStationで動作するプログラムのPlayStation2へ移植を行ってきた。移植はアーキテクチャーに依存するレイヤーとアーキテクチャーに依存しないレイヤーに分割し、依存レイヤーの部分のコードを書き換えてきた。（図\ref{fig:porting})しかし、それではアーキテクチャー依存間の差はとることは容易ではない。そこで我々がリファクタリングを用いて開発を行った。\\
ソフトウェアは一気に構成される訳ではなく、いくつかの変更を得て作られていく。新しい環境で使われるように変更すれば、再利用しやすくするために同じ動作をするプログラムを異なる構成に変更することもある。これらをリファクタリングと読んでいる。
\begin{figure}[htb]
\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上への移行がよりスムーズになる。\\
\subsection{デバッグ}
シーケンシャルな環境と並列分散の環境でのデバッグは難しさがだいぶ異なる。\\
シーケンシャルなアルゴリズムでいったん実装した後、Cellの環境に容易に移すことが可能ならば、Cellの並列環境の上でデバッグを行う必要がなくなる。シーケンシャルな環境で実装する際にもスレッドを使わないようなデバッグが容易にできるようなプログラム記述が求められる。
\section{まとめ}
我々は開発段階としてシーケンシャルなアルゴリズムでの実装、SPUにマッピングするデータ構造を用いたシーケンシャルアルゴリズムでの実装、Cellへのマッピングという風に開発を行った。そうすることで新たなゲーム開発環境ができたときもシーケンシャルなアルゴリズムから開発できるというメリットがある。またデバッグを行うことが難しい並列環境に置いても、それをより容易にデバッグすることを可能にした。