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

(2014/08/29)

最近ライブ壁紙に一段と興味が湧いてきた。
そもそも待ち受けしてる時点で（電波を発して）割とバッテリー減るし、
ライブ壁紙はAppWidgetと違って非表示になった瞬間に通知を受け取れる＝動くのはホーム画面が表示されている間だけ
なので、これからは積極的に使っていきたい。

AppWidgetのボトルネック

AppWidgetでどんな処理が重いかチェック等。
RemoteViewsのsetImageViewBitmap()を使った場合、
後でBitmapを書き換えても影響がない事から指定したBitmapの中身はコピーされてるようだ。

あまりAppWidgetで秒間20フレーム描画したいなんて人は居ないだろうが
頻繁にBitmapの書き換えによる更新処理をしたい場合、このコピーがボトルネックになる。
具体的に言えばASUS MemoPad HD7で128x128を1秒間に20回転送すると、もうそれだけでHomeの動作が重たくなり
2つ以上置こうものなら悲惨な状態だ。
予め描画しておいたワイヤーフレームのキューブをBitmap切り替えで表示する手は
上記の通りBitmapの転送がネックで速度がリアルタイムでやる場合と殆ど変わらなかった（のでボツ）
表示に関してはハードウェアアクセラレーションが効くのか複数のImageViewを半透明で重ねてもそれ程遅くならない。
同じワイヤーフレームモデルを解像度違いで複数描画し重ねて簡易ブルーム表現という手が現実的なものに。

意外だったのはバッテリーの減りで、試しに
スリープ時やHome画面非表示の対策を一切行っていないAppWidgetを
5個程置いてスリープ状態で放置したら6時間で2%しか減ってなかった。
（このタブレットは余計なアプリを無効にすればスリープ時のバッテリー消費がほぼ0%）
もっとバカ食いするかと思ってたが・・
まぁでも無駄にバッテリー食ってるのは確かなので対策するけど。

土台は整った

バッテリーメーターを作るのに必要な調査は終わった感じ。
後は素材を用意して実装するのみ。

(2014/08/28)

立方体の描画は、要するにワイヤーフレームをソフトウェアレンダリングするだけなので
前回ラスボスと言ってた割に特に詰まるところはなく終了。
ワイヤー自体もぼかしたいので解像度を低くしたBitmapを拡大、半透明で重ねてみたりした。

AppWidgetのスリープ

問題はそれより「AppWidgetが表示されてない状態の検知」だった。
普通に考えて端末のスリープ時は勿論のこと
AppWidgetが置かれているホーム画面が隠されている、
つまり何かしらのアプリが起動されている時はバッテリーの無駄なのでAppWidgetの更新を止めたい。
でも、見た所そんなAPIは無い。

とりあえずググると
googleの何かのメーリングリストで同じような事を聞いてる人も居て
「そもそもAppWidgetで頻繁な更新かけるな」みたいな回答されてたり。
（というか、検知できるのか？と聞いてるんだから無理なら無理と答えればいいでしょうに・・）
APIの設計から考えてもAppWidgetを30分より短い間隔で更新をかけるのは基本的に想定されていない模様。
アナログ時計widgetの1分間隔がいいとこか。

他の検索結果をあたってもどうやら画面ON/OFF(ACTION_SCREEN_ON/OFF)とユーザーが画面ロックを解除したタイミング(ACTION_USER_PRESENT)を検知してせめてロック時、スリープ時だけは更新を止めるのが
精一杯らしい。
うん。秒間10〜20フレーム更新するAppWidgetは論外だね。

どうするか

ここまでをまとめると
『秒間10フレーム以上の更新をかけたい』
『端末のスリープしか検出できない』
『端末使用時でもバッテリーのバカ食いは避けたい』
一見矛盾するこれらの要求、何とかなりませんか？
100%は無理でも50%位は出来ませんかという訳だ。

とりあえずAPIのリファレンスを一見関係無さそうな物も含め、ざっと眺めると
ActivityManagerのgetRunningAppProcessess()なんかの
現在走ってるアプリやサービスを取得する関数が使えそうな気配がした。
これを適当な間隔（5秒に1回など）ポーリングして
ホーム画面がRunningでなければそれは他のアプリが走っている事を判定できるのではないかと踏んだ。

しかしAndroidでアプリがRunning状態というのは必ずしも画面に表示されているとは限らず
管理の都合上の話であり、言ってみればonStopのかかったようなアプリもリストに入ってしまう。
よってRunning〜系はアテにならなかった。

他に使えそうなのはgetRecentTasks()。
こいつは最近起動したタスク（アプリやサービスと何が違うかはよく知らない）を最後に起動した順番で任意の数、取得できる。
間近に起動したアプリがホーム画面ならば・・という訳だ。
色々な端末での確認は必要だが今の所（少なくともエミュレーター上では）上手くいってる。
Androidはホーム画面を自由に差し替え出来るのでパッケージ名等は使えず、アプリのカテゴリで判断(Intent.CATEGORY_HOME)することにした。

続く

(2014/08/27)

Androidについて調べてると
「スリープ状態から30分間隔でウェイクアップしてんのは多分、updatePeriodMillisで安直にonUpdateかけてるAppWidgetのせいだな」
等分かってちょっと楽しくもあり、覚える事も割と多く大変でもあり・・

AppWidget

どうやらAndroidにおいて単にWidgetと言うとGUI部品全般、
AppWidgetはホーム画面に置くアレを指すようなので
自分が作ろうとしてるバッテリーメーターは今後AppWidgetと呼ぶ事にする。

前回から更に「AppWidgetで何とかアニメーション出来ないか」色々試行錯誤した所、
主にImageViewについて、大体以下の事がわかった。

• ImageView

  可:
     -> Alpha値の変更
     -> 画像の差し替え
     -> スプライトアニメーション
     -> 表示・非表示の切り替え
     -> パディング値をいじればオフセット移動も出来る・・か？
  不可:
     -> 回転、スケーリング

• AnalogClock

  針の回転表示を使えば画像の回転が出来るのでは？と考えたが、時刻が自由に設定出来ないので実質不可

スプライトアニメーションはAnimationリソース（animation-listタグで始めるやつ）としてXMLで記述し、リソースIDを指定する箇所で
Drawableなリソースと同じように指定すれば使えた。
ImageViewでなくてもViewを継承していれば行けそうな気がする。

パティング値の変更で画像をずらせるのは確認したけど
絶対座標で自由にという訳でも無いので”？”としておいた。

作りたい物

実はとあるゲームのUIに似せたバッテリー残量メーターを作ろうとしていて、
そこに入れたい処理は画像がゆっくりと輝くアニメーション、
独自フォント（数字）での残量表示、バッテリー残量に応じた色味の変化・・・
詳細は後のお楽しみとして、ここまでで想定した処理の半分くらいは実現できそうな見通しが立った。

残りはラスボス、ワイヤーフレームで立方体の描画。
Viewクラスがマトモに扱えない以上OpenGLやCanvasに頼るのは初っ端から諦めて
Bitmapへ自力描画してImageViewにセットという形だろうか。
幸いにもその立方体は自由自在に拡大縮小、回転するタイプではないのである程度のパターン（32フレーム分とか？）
を一括描画したら後はそれを切り替えるだけという形で実装できれば良いが。
果たして速度が出るのか、AppWidget如きがBitmapを何十個も作ってAndroidにｺﾞﾙｧされないのか等、その辺よくわからん。

(2014/08/26)

Android Studio

前々から名前だけは聞くAndroid Studioってなんじゃろか？と思って試したりした。
ちょこっと触ってみたら、今まではEclipseのプラグインでなんとかしてたけど
もう少しちゃんとAndroid向けにカスタマイズしたIDEを用意しようじゃないかという物？という印象。
ビルドシステムがGradleとかいうのに変わったらしく、ディレクトリ構造も変化していて
細かい所は知らんけど普通にビルドするだけならすぐ慣れた。
Androidエミュレータ(AVD)や、SDK管理ウィンドウなんかの外部ツール呼び出してた箇所は全く一緒。

AppWidget

サンプルやチュートリアルを見ながらバッテリーの残量表示やアラーム通知を実装したりして
AppWidgetでどんな事が出来るのかについては大体把握した模様。

結論から言えば描画、特にアニメーション関連が厳しい。
AppWidgetでは使えるクラスが制限されていてリファレンスを見ると以下のものしか対応していない
Layouts:

• FrameLayout
• LinearLayout
• RelativeLayout
• GridLayout

Views:

• AnalogClock
• Button
• Chronometer
• ImageButton
• ImageView
• ProgressBar
• TextView
• ViewFlipper
• ListView
• GridView
• StackView
• AdapterViewFlipper

一応画像を表示することは出来るものの、それを動かしたり何なりはちょっとしたトリックを使わないと難しい様で。
なんせViewクラスを直接触れず、RemoteViewsというインタフェースを通してしかGUIをいじれないものだから
RemoteViewsに用意されてるTextViewならそれ用のメソッド、
ImageView用のメソッド等を呼んで出来る範囲でしか操作できない。

ところでXperiaにデフォルトで入ってるお天気widgetは
半透明の雲画像を2,3枚重ねてスクロール表示してるんだけど
これどうやってるんだろう・・凄く気になる。

で、自分がやろうとしてる事はワイヤフレームによる立方体の描画なのだから早速手詰まり感が漂っている訳だが。
あとRGB指定で背景色を変化させたい。
これはImageViewに自前描画したBitmapをセットすることで実現できそう。

(2014/08/22)

json_archive

前に作ったboost::serializationでjson出力する代物。
作ってから一体どんな時に便利なのかますますよくわからなくなったがバグ修正位はという事で色々直しといた。

androidとか

以前ちょろっとやったけど最近またandroid関連に熱が入って調べ物とかしてる。
ゲームは勿論だが今回は特にLiveWallpaperとWidgets。
LiveWallPaperは文字通りホーム画面の背景でダイナミックな映像や役に立つ情報（天気とか？）を表示する物で、
Widgetsはアプリのボタン類と一緒に並んでる、バッテリー表示やらGPSやらですな。

で、そんなに探しまわった訳じゃないけど
所謂これだ！っていうデザインと機能を兼ね備えたのが中々無い。
もっと言えば「これだ！これなら貴重な携帯端末の片隅に置いてもいいしバッテリーも少しなら食っていい！折角だから俺はコレを選ぶぜ！」とか、そんな感じのが。

自分はシンプル主義なもので何やら派手派手な奴とか
やたらと通信してバッテリーを食いそうな類は入れないタチだ。
例えば手元にあるASUS MemoPad HD7のホーム画面はこんな感じ

imageプラグインエラー : ご指定のファイルが見つかりません。ファイル名を確認して、再度指定してください。 (ScreenShotA.png)

メール等は上部のバーに通知されるから別にWidgetsで置かなくてもいい、
ニュースも情報が無理やり押し付けられるようで好かない。
背景画像は無難でアイコンが見やすければ良いみたいな感じで。

で、そんな中で残ったWidgetsが画像左上のバッテリーメーターと右下のタスクマネージャ。
両者共にシンプルでデザインも宜しく、見やすいのだが
こいつはASUS製なので他機種では（恐らくゴニョゴニョしてAPKを抜き出さないと）使えない。
困った -> バッテリーメーター位だったらすぐ作れるのでは？という流れで勉強開始。
出来たらGooglePlayにでもアップしたい。
前置きが長かった・・・

LiveWallpaperの方はついでだけど
もし自分が気に入るようなのが出来たら格好いいし使いたいとは思ってるので。
要はバッテリー消費 < 魅力

ちなみにデザインは一応考えてある。
ただLiveWallpaperの方はモデルファイル出力のテストも兼ね
自前エンジンによる描画を考えてるから中々壮大かもしれない。

PCの電源が・・・

KRPW-P630W/85+　を使用中。だがそろそろ寿命かもしれない。
突然落ちたり立ち上がらなかったりは一度もないものの、微かな異臭がする。
PCの電源は鼻を近づけると独特の臭いがすると思うけど
それが負荷をかけたりして温まるとそれがふわ〜っと周辺まで広がってくる感じ。
焦げ臭いとは違うのだが（ケミカル臭？）とりあえず体には良く無さそうである。

買ったのは3年半前でほぼ毎日、時には付けっぱだったんでタイミング的に
早すぎず遅すぎずといったとこか。
いきなり発火発煙されても困るし、なにより心配しながら使うと作業に集中できないのでさっさと新しいの(KRPW-N500W/85+)を注文した。
これは容量はともかく今のやつの後発バージョン・・かな？
最近出たばかりらしくレビューがまだ殆ど無いのが心配ではあるが。まぁなるようになるか。

(2014/08/19)

Google Site

ちょっとWebGLを使って何かしたいけど、それだけの為にレンタルするのもなぁ・・と思ったので無料で出来そうなサービスを物色。
といっても前々から気になってたGoogle Siteを試しただけ。
こいつは言ってしまえばここが使ってるAtWikiのGoogleバージョンで、
HTMLやJavascriptを直に置くのではなくweb上のツールで簡単な設定を行うことでそれっぽいwebページが作れるというシロモノである。
phpやsqlを駆使するような凝ったページは無理というのも同じ。

ただしGoogleなので（？）広告は出ないし
サーバーも繋がりにくいとか遅いという事もなく安定している。
これから軽くwebページ作りたいという場合はこちらが良いのではないかと思った。
（添付ファイル含め100MBまでってのが地味にネックかも）

本題のWebGLが使えるのかという点だけど・・スクリーンショットの通り、一応使えてはいる。
でもセキュリティの観点からか直接は置けないので一旦gadgetとして作り、それをURL指定で置くという形になる。
同じページに添付ファイルとしてjsファイルを置けばいつも通り<script>タグで読み込める。

欠点は前述の通り一旦gadgetにするのが意外と手間なのと
添付ファイルの一覧がページ下部にずらずら表示されて格好悪い事か。
それだけっちゃぁそれだけなのだが。

当然ながらゲームを作ったとしてもハイスコアは保存できないし
折角javascriptを書くのに操作するのはgadgetの内側だけでページのメニューその他は
google siteのテンプレっていう中途半端感があるのも事実。
だったら広告入ってでもatpagesに登録して自前のhtmlファイルにphpやsqlを使うか迷う所ではある。

あとDropboxでもhtmlとjavascriptを使ったページのホスティングは出来るようで、こちらは
HTMLファイルとjsをポンと置いて動かせるみたいだ。
単にWebGLで何か動かしたいだけならこっちがいいのかも。
後でどっかのサーバーにアップしたい時にそのままコピーできるし。

(2014/08/17)

絵を更新。前に「金網が〜」って言ってたのとは別物。
自分の性格上、ずっと同じ絵ばかりでは飽きが来るので幾つか同時進行している。
Drawing(analog)

(2014/08/09)

Json Archive

モデル出力を何形式にしようかと思って候補としては

• バイナリ
• テキスト(独自フォーマット)
• JSON
• XML

が挙がった訳だけど。
独自のテキスト形式はフォーマット考えるとこからして面倒で退屈、速度的にも微妙なので即却下。
XMLやJSONは既存のライブラリが使えるのでそこは楽だし、デバッグもしやすい。
バイナリは訓練してない人間は読めないが速度の面じゃ一番良いだろう。

一番いいのはデバッグ中はテキストで、後でバイナリなのだが・・はて。
とか10分程悩んでたら、ふとboost::serializationを思い出した。
これならarchiveを取り替えればXMLとバイナリの両方に対応できる。素晴らしい。

だがXMLは見た目がごちゃごちゃしてあまり好きじゃないので、JSONを使いたい。
そうすれば出来心でwebに持っていったとしても何とかなりそうだし。
jsonのarchiveはboostに標準添付されてないので何処かから持ってこなければならないのだが、
探し方が悪いのかググってもメモリ上のjsonツリーをboost::serialization通して(text/binary/xml)出力するものばかりで
肝心のjson出力が出てこない。

そうこうしてるうちに自分で作り始めてて、気がついたら割と動く（？）ようになってた・・・というのが事の成り行き。
割と動くんだったら公開しなきゃ損だよなというんで、GitHubに上げてみた。
ポインタの復元やクラスのバージョン管理とかはソースを追ったわけではなく見様見真似なので間違っている可能性大だが。

(2014/08/05)

拍手

ちょくちょく頂いてるようで、モチベーション維持に役立っている。
お礼の絵をバリバリ用意できるよう頑張りたい（いつになることやら）

モデルが・・

あれ、進んでないじゃないの？って感じのモデルエクスポータ。実際進んでない。
だってまだこんなんである。見た目の点で先月から殆ど変わってない。
TF3DMからFBXモデルを適当に持ってきて見栄えは良くしてみたものの・・

ノードをクリックしてグリグリと回転したりなど

というかこれまでに何度か組み直している。
CUIアプリケーションやゲームのように自分で処理全体を管理する癖が染み付いてしまっているせいか
テキトーに組んでて後になって全然クラス間のやりとりが上手く行ってないケースが頻発。
描画についても然り。
GUI初心者である自分は、イベント駆動という事を強く意識してないと簡単にハマってしまう。

先日これは流石に不味いとの事でGoFのMediatorパターンで組み直し
これはなんとか動いている。

モデルインポートダイアログの動作としてはFBXの読み込み、メッシュの解析、
通常のメッシュはそのルートノード名を、スキンメッシュは名前にアスタリスクを付けてリストボックスへ表示。
リストからメッシュを選ぶとUV, 法線、頂点カラーそれぞれのチャンネルを調べ右側のコンボボックスへ表示
マテリアルはBlenderの吐き出すFBXがテクスチャを上手く扱えてない関係で手動で関連付けする。
スキンモデルは複数のメッシュで構成されることがあるためリストから複数選択可になっており、
その場合頂点やポリゴンインデックスは1つに合成される。

で、上記の項目を何か変更する度にプレビューへ即座に反映される仕組み。
（前は手動と自動を選べる様になってたが面倒くさくなった）

プレビュー画面ではノードを右クリックすると選択でき、左ボタンドラッグで回転、中ボタンドラッグでスケール変更など。
ノード姿勢のリセットは右側のreset nodeやreset allボタンで。

プレビューでひと通り確認できたならOKボタンで抽出し、メインウィンドウにそれが渡される予定。

そういえば

あれ？こんなに何もやってなかったっけ？と思ってgitの履歴を眺めると
どうやらテストコード書きと、それで見つかったバグ修正に励んでたようだ。
特に対数クォータニオンの補間誤差が大きい事に悩んでた様子（他人ごと

絵

次をチマチマとやってるが
毎回ふと描きたいと思ったものを自分のスキル考えず取り掛かってしまう為、例えば
「金網を斜め視点で描くときどうすんの？」->ちょっと描いてみては消し、暫し考えた後、また描いては消し・・
といったような風にいちいち作業が停滞してしまう。
上の通り、現在は金網に四苦八苦。
あれは真正面から見れば針金がジグザクになってるだけだが実は結構奥行きがあるんだよね・・

なお次回までに完成等と宣言してしまうと
完成するまでwikiを更新できない悪循環に陥るので絵については今後も不定期、出来次第載せる形にしたい。