演算負荷を意識しはじめる

背景のエフェクトは解像度や各種演算精度をダイエットして負荷を節約することとしても、肝心のゲーム部分でも光の散乱や逆光とかパーティクルといったエフェクトを多用するイメージでいるため、なにやら早くもハードウェアリソースを最大限活用する必要がありそう。

CPUさんにはlibpdの動作のほうをがんばってもらう必要があるので、グラフィックについてはGPU/ソフトウェア処理を問わず、しっかり60fps出るように速度をチューニングできる余裕（＝自分の知識、理解）を作っておきたい。

そうなってくると、動作テストのリファレンススペックのようなものを想定しておかないといけない気がします。



開発環境である2006年のボロMacのGPUはこんな感じ。

Device	GPU	Shader Clock	Vertex Shader	Pixel Shader
iMac Early2006	Mobility Radeon X1600	475MHz	5 units	12 units

テスト機である初代Nexus 7のSoCであるTegra 3の他、動作ターゲットにしたいと思っているAndroid 4.1標準搭載機種に採用されている主要なSocのグラフィックスペックを俯瞰してみます。

Device	GPU	Shader Clock	Vertex Shader	Pixel Shader
Tegra 3	ULP GeForce	520MHz	4 units	8 units
OMAP4460	PowerVR SGX540	384MHz	2 units	4 units
Snapdragon S4	Adreno 225	400MHz	unified
Exynos 4412	Mali-400 MP4	440MHz	1 unit	4 unit

7年も前のPCとはいえMobility Radeonのほうがテストでfps数が高く出てるのも、数値的に比べてみるとある程度納得です。まぁ他にもALUないしMAC（積和演算器）のスレッド数やそれらに付随するキャッシュなど、クロックやコア数だけでは語れない部分もモバイル向けでは削減されているため、PC向けGPUのほうがさらに高性能という重み付けができますね。

とはいえ、シェーダでやることは基本的に「同じ数式をひたすらぶん回し続ける」という処理なので、同じセグメントの製品であればコア数やクロック数に応じてある程度リーズナブルにパフォーマンスを見積もれるのではないでしょうか。

Tegra 3が載っているNexus 7では相当な余裕を残して動くくらいでないと、同時期のGalaxyとかXperiaあたりではガクガクになってしまうなぁ、という程度の見積もりを持っておくのが妥当かなぁと思います。

ちなみにゲーム機では

Device	GPU	Shader Clock	Vertex Shader	Pixel Shader
PS3	RSX	550MHz	8 units	24 units
Xbox 360	Xenos	500MHz	unified 48 units

といった感じ。最近のグラボや次世代ゲーム機はコア数が軽く1000を越えます（！）

一方、そんな方面ばかり見ていてもスマホゲームが作れませんので、シェーダを使わずにイルミネーション的処理をしていたDCやPS2、PSPあたりでどのような見せ方をしているかも研究しようと思います。

2Dゲームなんだから全部絵をかいて済ませるというのも一つの選択肢ですが、そうするとそもそもまともな絵が描けないので誰かにお願いする必要が出てきます。自分自身、動きを含めた全体的なデザインをディレクションできるほどグラフィックのイメージを固めているわけでもないので、わりと丸投げに近い形になってしまい、結局アウトプットとしては「スキン」ができてくるだけ。これは音楽になぞらえて言うと、BGMに合わせて合いの手入れてるだけの音ゲーと似た状態でヤダ。自分がわざわざアプリ制作なんぞ考えはじめたキッカケでありモチベーションでもある、音楽とグラフィックとゲームを相互接続する実験的ゲームデザインからは遠ざかってしまいます。

プログラミングができるグラフィッカーみたいな人がいれば本気でお願いしたいですが…
デモシーンとかやってる人で興味ある方、いらっしゃいましたら詳しくお話させて下さいｗ

ところで私、仕事が半導体屋なんですが、扱っているのは製造プロセスが中心で、ゲーム関係で言うとこういうネタにばかり食いついていたんですが、概念的な理解にとどまっていたプロセッサアーキテクチャ方面のネタもある程度体で理解が進むようになってきたここ最近です。