2012年09月27日

ライブ壁紙はプレビューとホームどちらで実行されてる?

今日はメモ代わりの小ネタです。

Android のライブ壁紙を作っているうちに、アプリがプレビュー画面で実行されているのか、
それともホーム画面で実行されているのかを区別する必要がでてきました。

検索してみると同じ事で悩んでいる人の質問を発見。

http://stackoverflow.com/questions/9788784/how-do-i-detect-whether-my-live-wallpaper-is-running-in-the-preview-set-wallpap

WallpaperManager から実行中のライブ壁紙のクラス名を取得して、それが自分の名前と一致していればホーム画面で実行されていると判定するみたいです。
なお、上記サイトでは判定コードを WallpaperService.onCreateEngine に書くとありますが、手元にある Android 2.3.3 ではうまくいきませんでした。
確かにライブ壁紙選択画面からプレビュー画面に移った時には onCreateEngine が呼ばれますが、
そこから決定ボタンを押してホームに戻った場合は onCreateEngine は呼ばれません。
おそらくインスタンスを使いまわしているのでしょう。なので判定コードは WallpaperService.Engine.onVisibilityChanged に書くのがよさそうです。
posted by JUNOSOFT at 18:35| Comment(0) | プログラミング

2012年09月23日

白バージョン

スク水描いたんなら色変えて白も作れよ!と怒られました。

理不尽な気もしましたが、なるほど作るべきですよね。
いや、決して私自身がスク水好きとかそういうわけではなく(以下略)
120923.jpg
posted by JUNOSOFT at 01:02| Comment(0) | 雑談

2012年09月21日

衝突判定

こんにちは、暑さでSAN値が削られているプログラム担当です。
エース・オブ・ワンドは難航続きで衝突判定ひとつとってもわりと苦労したのですが、その話でも。
最初は何も考えずにキャラクタ配列同士をループで回して衝突判定をしていました。
例えばプレイヤーの弾が20発あって、敵が30匹いるなら判定回数は
20x30 = 600回。これを毎フレームやっていることになります。

最初は良かったのですが、さすがに速度的に厳しくなったので、すこし気合を入れて効率重視の判定を作りました。
イロイロ試して最終的に取り入れたのがKD木による判定木の導入です。


Wikipedia - Kd木
http://ja.wikipedia.org/wiki/Kd%E6%9C%A8


キャラクターの衝突判定をKD木のノードに登録して、衝突している可能性のある衝突判定同士だけ判定しようというわけです。

二次元の当たり判定だと4分木を使うことが多いかと思いますが、横スクロールアクションでは上下方向よりも左右方向にキャラクターが散らばっていることが多いため、
4分木における上下左右に分割」というのはちょっと無駄な気がしました。どちらかというと上下よりも左右に分割したいと。そこで目をつけたのがKD木です。
KD木だと画面をまず左右に分割、次は上下に分割、次は左右に分割 といった感じで、階層を一つ深くする毎に分割方向を変えていきます。一階層での分割は一回のみです。
4分木みたいに上下左右4つの空間に分割しながら掘っていくのではなく、上下または左右2つに分割しながら掘っていくので多少単純になります。

エース・オブ・ワンドでは、KD木の法則を少しだけ変更して、分割方向を左右→上下→左右→上下 と交互にするのではなく、分割後の空間がより正方形に近くなるように分割方向を決めています。

たとえば左右に極端に長い空間の場合、機械的に左右→上下→... と分割していくと、恐ろしく横に細長い空間に分割されてしまって、あまりよろしくありません。
そこで、現在の空間の幅と高さを見て、長い方の辺を2つに割るように分割してくようにしました。たたとえば横60x縦10の空間内で衝突判定をしようとした場合、
1回目、横長なので左右に分割 60x10 --> 30x10
2回目、横長なので左右に分割 30x10 --> 15x10
3回目、横長なので左右に分割 15x10 --> 7.5x10
4回目、縦長なので上下に分割 7.5x10 --> 7.5x5

という感じで、衝突判定が複数の分割空間にまたがってしまうか、予め決められた最小空間サイズに達するか、あるいは最大深さにまで達するまで続けます。
こうすると分割空間が極端に細長くなることがないので、キャラクタの衝突判定のほとんどが正方形に近いという前提なら、効率良く判定を保持させることができます。
とりあえずこれで計算回数が劇的に減り、衝突判定に悩まされることはなくなりました(^^
posted by JUNOSOFT at 20:38| Comment(0) | プログラミング

2012年09月03日

Macに移植

こんにちは、プログラム担当です。

マスターアップも終わり、若干気持ちに余裕ができたので少し新しいことにチャレンジしてみました。

Battle Tank SWORD や RIRIKO Bocket Billiad は最初から Android 向けアプリにするつもりだったのですが、ある程度動くものが出来上がるまでは、VisualC++ で開発していました。まずは Windows 上で動くものを作って、ある程度形になったら今度はそのソースを gcc でコンパイルできるように若干修正し、最終的に NDK を使って Android 向けにビルドしました。つまり Java で書いたのは OpenGL の初期化、タッチパネルのイベントの取得、サウンド処理だけで、ほとんどすべての処理は NDK で作成したライブラリに投げています。

これで Windows と Android で動くハイブリッドコードができたので、今度は Mac / iOS 上でも動くようにしてみたいと思います。ただ、それにはでっかいハードルが。MacOS 向けはともかく、iOS に対応するにはまず Objective-C を覚えなければなりません。これは面倒くさい…。なるべくなら必要最低限の Objective-C コードを書くだけで済ませたいものです。

で、iOS への移植を考えるのは後にして、とりあえず MacOS で動く Battle Tank SWORD を作ってみることにしました。なぜなら、MacOS 向けアプリなら C++ でも作成できるからです。ひとまず MacOS で動けば、そこから iOS に移植するのは簡単なんじゃない?同じメーカーのOSなんだし。という楽観的な予想です。

というわけで、XCode + Cocoa Project + GLUT を使って MacOS 版を作ってみました。XCode も初めてですが、いろいろなエラーを直しているうちにだんだん XCode にも慣れてきました。もともと gcc でコンパイルできるように作っただけあって(あと OS 依存部分を GLUT に丸投げしたおかげ)、あまり大きなエラーもなく MacOS 上で動くものができました。

さて、問題は iOS への移植です。まず最初に思いついたのは、Windows 上で動作確認をしながら C++ で書かれているソースコードを全て C に書き直し、それを XCode に持っていて Objective-C とつなげる、というやり方です。Objective-C は C と互換性があるため、C で書かれたプログラムを iOS で実行するのはとても簡単です。C++ から C への書き換えは、常にコンパイル・実行可能な状態を維持しながら少しずつ行えるので、一気にすべてを Objective-C に書き換えてしまうよりかは遥かに安全かつ楽です。が、それでもほとんど全てのコードを書き換える必要があるというのは面倒です。

そこで少し調べてみると、どうやら C++ でプログラムを書くことのできるフレームワーク Karakuri Framework というものが存在するらしく、それなら移植の手間はほとんどなさそう。ただ、できることなら標準で提供されているライブラリだけでどうにかしたい...

C++ で書いたプログラムのままで、なるべく標準提供されている環境だけを使い、OS やコンパイラの差異を #ifdef だけで吸収できる方法はないものかと、さらに調べてみたところ、ありました。Android における NDK と同じ仕組みで、iOS 向けのライブラリを C++ で作ってリンクする、という方法です。

iOS に対応できるようにいくつかの項目を #ifdef __APPLE__ などで切り分けておき、XCode で iOS 向けのライブラリとしてビルドします。エクスポート関数部分だけは Objective-C で書く必要がありますが、たいした手間ではありません。

C++ のプログラムを iOS ライブラリにする方法については、以下のサイトを参考にさせていただきました。

 iOSで静的ライブラリを使う
 http://d.hatena.ne.jp/white_wheels/20110827/p1

これで見事に iOS シミュレータ上で実行できるようになったのです!尤も、実行できるだけで、OpenGL まわりで実行時エラーが発生しまくってますけど。

ただ、別 OS への移植というのは、コンパイルが通ってリンクもできて実行できるようになるまでが全体の手間の9割を占めていると思っています。画面が崩れようが実行時エラーが発生しようが、実行さえできてしまえばこっちのもの。ゲームそのものは正しく動いている訳ですから、あとは OS 依存部分、ファイルアクセスやマウス入力、サウンド再生ができるよう対応していけばいいのです。

Windows, MacOS, Android, iOS すべてに対応したゲームを作るというのは自分の夢だったので、これはほとんど叶ったも
posted by JUNOSOFT at 00:13| Comment(0) | プログラミング

2012年09月01日

Androidでステンシルバッファ

こんにちは、扇風機が手放せないプログラム担当です。
今日は短いネタ。
某所でステンシルバッファの話題があり、Androidでのステンシルバッファ不具合についてのまとめを見つけました。
参考にどうぞ。
http://gorry.haun.org/pw/?stencilbug
posted by JUNOSOFT at 00:52| Comment(0) | プログラミング