進捗状況(2013/04) - FPSを作ってみる@wiki

(2013/04/25)

spirit

はい、例によって例のごとく。
spiritは文法を覚えるまでが大変。特に何がコンパイルエラーが訳わからん事が多いので結局1行1行コメントアウトしながら原因を探るしかなく、
しかもコンパイル時間が30秒掛かる事はザラなので時間があっという間に過ぎる。
デバッガで追った所で中で何が起こってるかもわからない。
そんな調子なので、次回以降何か文法解析したい場面に出くわしてもあんまり使う気にならない。
使うことのメリットは確かにあるのだけどデメリットもでかい。C++でちょっとテンプレート使える程度のニワカが触ると火傷するライブラリ、それがspirit。

OpenGLメソッドの呼び出し

で、エフェクトファイルの文法解析については数日前になんとか実装していたのだが
今度は読み込んだ設定項目（= 値を格納した構造体）からどうやってOpenGLメソッドを呼ぼうかという話になる。
具体的にはレンダリング設定を変更するメソッド。

例えば深度チェックを切り替えるGL_DEPTH_TESTやポリゴンの表裏に依るカリングGL_CULL_FACEなんかの
On/Off切り替えなら
呼ぶ関数は全てglEnable() or glDisable()であり、引数のフラグが違う程度なのですんなり行く事は想像に難くない。

struct BoolSetting {
   bool    bEnable;
   GLuint  flag;
 
   void action() const {
      if(bEnable) glEnable(flag);
      else glDisable(flag);
   }
};
 

とかやっとけば終わりだ。

問題はそれ以外の項目。
深度バッファの幅を切り替えるglDepthRange(float,float)や、
サーフェスへのレンダリング範囲を指定するglViewport(int,int,int,int)という感じで
メソッドと引数の型、数も全てバラバラである。これはどう対処すればいいか。

真っ先に思いつくのはswitchで地道に1つ1つ書く方法。
これはまぁ、デバッグはしやすいし今回はOpenGLのサブセットであるOpenGL ES2なのもあって全部書いたとしても30項目も行かないレベル。
でも将来的にOpenGL4に対応させるつもりなので却下。

次にアセンブラで自力で引数をスタックに積み関数をコールする方法が浮かんだが
この時代にタイムクリティカルな場所でもないのにアセンブラは「無い」でしょうという事でこれも却下。

ならば可変引数テンプレートで何とか・・と、途中まで考えたものの面倒くさくなって放棄（ｴｰ
多分上手い人が組めば出来るかも。

結局たどり着いたのはマクロ。
折角boostライブラリを入れたのだからって事でboost::preprocessorを勉強した。
spiritで構造体をadaptする時とかちょくちょく登場していたのでこれを機に。
名前の通りプリプロセッサを使って色々しましょうというマクロ群で、spiritに負けず劣らず変態ライブラリである。
話が長くなったので結論を述べると

using MyGLFunc = std::function<void (const ValueSetting&)>;
   struct ValueSetting {
      int func_id;
      float value[4];   // 引数は最大4つまで対応。intもfloatとして持つ
      float operator()(int n) const { return value[n]; }
 
      static MyGLFunc c_func[];
 
      void action() const {
         c_func[func_id](*this);
      }
   };
 
   // (キーワード, OpenGL関数名, 引数の数) のシーケンス
   #define SEQ_GLSETTING ((linewidth,glLineWidth,1))((depthrange,glDepthRangef,2))   // あと色々定義
 
   #define PPFUNC_GLSET_ARG(z,n,data) (data(n))
   #define PPFUNC_GLSET_FUNC(ign,data,elem) [](const ValueSetting& vs){ \
      BOOST_PP_TUPLE_ELEM(3,1,elem)(BOOST_PP_SEQ_ENUM(BOOST_PP_REPEAT(BOOST_PP_TUPLE_ELEM(3,2,elem), PPFUNC_ARG, vs))) },
 
   MyGLFunc ValueSetting::c_func[] = { BOOST_PP_SEQ_FOR_EACH(PPFUNC_GLSET_FUNC, NOT_USED, SEQ_GLSETTING) };
 

ソースから掻い摘んでコピペしたからもしかしたら違ってるかもしれない。まぁそこは各自補完してもらうとする。
SEQ_GLSETTINGのシーケンス中、キーワードが使われてないがこれはspiritのsymbol定義用。

じゃ、そんなとこで続きに取りかかる(・ω・)ノ

ちょっと前に作ってたベクトルクラスもboostのマクロでもっとスマートに書けそうな予感・・

(2013/04/19)

OpenGLの復帰処理に失敗する件

単にシェーダーを読み込ませるのを忘れてプログラムにリンクしようとしてエラーが発生していただけというオチ。
とりあえず再び以前の様にシンプルなゲームが動く状態まで持ってこれた。一件落着。

文法解析ライブラリ

では3Dへ・・・待った。その前にシェーダーやレンダーステートの管理を忘れてた。
現状のシェーダーファイル名をいちいち指定してリンク、glUseProgram()する形式のは面倒極まりない。
つまる所、DXのD3DXEffectのfxファイルで管理していたようなAlphaBlendのオンオフ設定やシェーダーの指定が
OpenGLだとヘルパークラスが無い関係上、自前で用意する必要がある。

んー
といっても基本的に設定項目と値のペアを並べるだけ、複雑な文法があるとしても精々構造体とかそんなのだから
正規表現(regex)でも使ってゴリゴリ書けばすぐ終わりそうな類の問題だが・・ここで何時ものアレ

”折角だから俺はこのboost::spirit(qi)を学ぶべきだぜ？”

で、

”や、でもYAGNIだし・・”

ささやかな抵抗も虚しく

”将来、複雑な文法解析で役に立つ。何時やるか？im(略”

押さえ込まれる。

という訳で2〜3日程度かけてboost::spiritを勉強した。
boost::spiritでググってヒットしたブログで皆さん「ちょっと使ってみた」みたいな感じで軽く言ってるけど
実際そんな生易しいものでは無いと思うが、どうだろうか。
公式のチュートリアルをひと通り終わらせた感想としては、ライブラリではなく新しいスクリプト言語1つ学ぶつもりで挑まないと厳しいかなと。

しかも自分の場合はspiritの関連ライブラリphoenixやfusionを知らなかったもんだからそれらのフォローも含め
どうしても手を動かす前に覚える事柄が多くて退屈してしまい、チュートリアルだけで睡魔に襲われること数回。
C++を使い始めた頃にDirectXの入門本を読んだ時以来かもしれない。

関係ないけどspiritはコンパイル長いねぇ

予定

話を戻して・・
アルファブレンドのオンオフ如きでユーザーに直接APIを触らせるようなフレームワークはフレームワークじゃねぇ！との事で
D3Dに用意されていたようなEffectクラスを作りたい所存。

要はアルファブレントやデプステストなんかの細々したセッティングをテキストファイルに書いてまとめたい。
ま、既存のを使えば良いかもしれない話だが折角のspiritの威力を試したいし、
それに自分で作るという事は常々抱いていた不満をぶちまけるチャンスでもある訳で。
複雑なものを作るつもりもないから3日もあれば終わるだろう（希望的観測）

(2013/04/16)

さて（略

チマチマとOpenGL化を進めている。とりあえず2D画像の表示まで出来た。
画像がカラフルなのは頂点の色設定やシェーダーの色合成などを確認する為。
OpenGLにセットする行列はColumn-majorだとか頂点バッファのオフセット指定は要素単位なのかバイト単位なのかで詰まってたりしたんで（これはJava特有とも言えるが）
思ったより時間がかかってしまった。
ちなみに後のC++移行を考えて敢えて簡易なGLSurfaceViewを使わず、EGLにて自前でOpenGLを初期化している。

スプライトの座標変換には2x3行列を使い、行列スタックを使ってシェーダーへ渡す。
シェーダーでは3Dの時と同じ様にテクスチャ参照なりする訳なので
これを3Dに拡張するのは難しくないと思われる。

残る問題

さっさと3Dでポリゴンぐりぐり回したい所だがまだ1つ問題が。
アプリケーションがスリープ状態になった後の復帰に失敗する。デバッガで追った所、どうやら原因は復帰処理（または周辺）にあるらしい。
本来OpenGLではDirectXで言うデバイスロストは発生しない筈なのだがAndroidでは他のリソースとの兼ね合いなのか
他のアプリが全面に来たりすると普通に起こる。
従ってDXと同じ様にグラフィック関連のリソースを最確保してやらねばならない。

これらの処理はデスクトップでDX9を使っていた時に一度組み込んでいたので同じ要領で行ける。楽勝・・・のはずだったのだが。
2度目の起動でシェーダーのコンパイルに失敗したとかいう、よくわからないエラーで悩んでいる。
リソース破棄&再確保のタイミングが不味いのか何なのか・・

(2013/04/11)

さて、ここらで進捗を書かねば。<- いつものまだモノ出来てないパターン

(Android)紐シミュレータの改良

紐シミュレータにの積分計算をVelocity-VerletからRungeKuttaやImprovedEularに変えて任意の更新間隔に対応してみたが
計算精度はVerletに比べてほぼ変わらず。
ま、こんなもんかという感じ。剛体の物理シミュでどれだけ変わるかが気になる。

(Android)グラフィック表示のOpenGL対応 <途中>

今まで描画にSurfaceView#drawBitmap()とかやってたんだけど将来を見据えてOpenGLに対応・・というよりはOpenGL自体の勉強。
具体的にはフレームバッファ（DirectXで言うところのRenderTarget）周りとか。
どうやってOpenGLのリソースを管理したらいいかな～と仕様を練ったり簡単な2D用行列クラスを用意、
他にはAndroidではDirectXのデバイスロストに似た現象が発生するらしいのでそれの対応策などを考えたり。

ちなみにこれはWebGLやWindowsで作ってるゲームのOpenGL移行への布石でもあって、
扱いに慣れてきたらそのうちグラフィック強化週間と称して新しい技術に挑戦する予定。
今考えているのはCascadedShadowMappingやLightStreaking辺り。ジオメトリシェーダーを使った2.5Dブラーも面白そう。
いやしかし、最近GPUの話題を追いかけてなくてすっかり疎くなってしまったな・・
2.5Dブラーが流行ったのは丁度ロストプラネットが出た頃だから自分のシェーダー知識はそこで止まってるという事か。

というかそもそも何でJavaで書いてるの～？という疑問に対しては
ゆくゆくはC++を使ったNativeActivityに移行するつもりだけどFloatBufferとかで
メモリ確保したりバイトオーダー指定でデータ格納したりなんてのはWebGLでもやる事なんでその辺の手順を覚えるのにいいかな～と。
中途半端も良くないし。若干こじつけだが。

SSEを駆使したベクトル、行列クラス実装 <途中>

毎度お馴染みの「前々からやってみたかったシリーズ」なのだが、一応それっぽい理由を付けると
現状のExpressionTemplateもどきが汎用性重視、関数のインライン展開を当てにし過ぎて
デバッグビルド時に動作が遅くハッキリ言って使いものにならない為である。
例えば凸形状の重複領域を求める処理がリリース時0.5ms程度で済む所、デバッグでは20ms以上もかかってしまってたり。
これは物理シミュレーションをしている時に問題となった。

一応、汎用性重視とある通りVector<8, double>とやれば要素がdoubleの8次元ベクトルを、
Matrix<32,32,float>でfloatの32x32行列を定義でき、次元があってれば演算も可能だが
実際の所ゲームじゃまず使われないのだった。

そんな訳で要件としては
「デバッグビルドでもそこそこ速く動く」
「SSEを活用 => インラインアセンブラだと64bit対応がアレなのでintrinsic関数を使う」
「（SSEレジスタが128bitな関係上）5次元以上のベクトルや幅が5以上の行列は考慮しない => サイズは2～4」
という感じに。

SSEではメモリからの読み込みが16byteアラインメントに合っていると高速に動作するようなので
float*4の4次元ベクトルはいいとして3次元ベクトルでそれはキツい。2次元は普通に計算したほうが速い？
じゃあと最初はコードの簡潔さ、綺麗さを考慮しテンプレートでAlignedとNoAlignedポリシーに分離させればいいじゃないですかという事で

// 16byteアラインメント
template <int N>
struct __declspec(aligned(16)) TagAlign;
 // 4次元用
template <>
struct __declspec(aligned(16)) TagAlign<4> {
	float v[4];
	__m128 loadPS() { return _mm_load_ps(v); }
	void storePS(__m128 m) { _mm_store_ps(v, m); }
};
// アラインメント無し
template <int N>
struct TagNoAlign;
// 4次元用
template <>
struct TagNoAlign<4> {
	float v[4];
	__m128 loadPS() { return _mm_loadu_ps(v); }
	void storePS(__m128 m) { _mm_storeu_ps(v, m); }
};
// 2次元用
template <>
struct TagNoAlign<2> {
	float v[2];
 
	__m128 loadPS() {
		// 0で埋める
		__m128 tmp = _mm_load_ps(&xmm_zero);
		// float2つ分だけ読む
		return _mm_loadl_ps(tmp, v);
 
		// 空きを0で埋めなくていいなら、次の2行の方が速い？
		// __m128 tmp;
		// return _mm_loadl_ps(tmp, v);
	}
	void storePS(__m128 m) { _mm_storel_ps(v, m); }
};
// ... あと色々定義
 
template <class Align>
struct Vec : Align {
	template <class AL>
	void operator += (const Vec<AL>& v) {
		storePS(_mm_add_ps(loadPS(), v.loadPS()));
	}
};
 
using Vec4A = Vec<TagAlign<4>>;		//!< アラインメント済み4次元ベクトル
using Vec4 = Vec<TagNoAlign<4>>;	//!< アラインメント無し4次元ベクトル
 

最初こんな風に書いてみた。確かにこいつは期待通り動いてくれるしリリース時に最適化も効く。・・のだが
デバッグ時はloadPSやstorePSによる関数呼び出しの嵐となってアセンブリを見た感じ非SSEで書くより数倍遅そうだった。
部分的にデバッグ時でもインライン展開してくれるような設定できないもんかな？とも思ったが、そんな都合よく行かないようだ。
残念ながら今回の要件に合わないのでボツ。
この後試行錯誤の末に結局マクロを駆使した手法に行き着いた訳だが・・長くなってしまったのでまた後日。

OpenGLとDirectX

OpenGLの調べ物をしているとDirectXとOpenGL両対応の話題をちょくちょく見かけるが
その辺の実装に興味も無い訳ではないが個人制作の範囲でそれは大変だし、自分が知ってるDirectXは9までというのもあり
ここは心機一転、PC用のプログラムもOpenGL一本で行くかもしれない。
ただやっぱりAPIの形態としてはCライクなOpenGLよりC++なDirectXの方が断然好きではある。

(2013/04/02)

DGFramework

ようやっと動くものが出来た。
描画にOpenGLを使ってないしスプライトのアニメーションも未対応、コリジョン周りがまだ煮詰まってないなど
問題もちらほらあるが一区切り。
バウンドする緑の球体が2秒毎に1個追加されるので、それをタップして避けるだけのゲーム。

DGはDegarashiFrameworkの略だがそんな事はどうでも宜しい。
サウンドはフレームワーク上には関数を用意してあるものの肝心の鳴らす音源を持っていない為、無音。
スクショ上げたんだからゲームもすぐにでもアップしたい所だが
Android-Appのリリース用設定？とか、マニフェストだかその辺をこれまでノーマークでやってきたんで調べる。暫し待たれよ。

変換が面倒なんでスクショの形式をjpgではなくpngにしてしまったけど、どっちがいいんだろうね？

#追記

RSエンジンと同じアップローダhttp://ux.getuploader.com/RSE/に
アップしてみた。
初めての公開でもしかしたら動かないとかありそうだけど、そこは大目に見て欲しい。
報告はバグ報告ページへ。

#追記2

折角だから前に作った2Dの紐シミュレータもアップロードしてみた。