FPSを作ってみる@wiki

09)

最終更新：2014年09月25日 22:00

slice

- view

管理者のみ編集可

(2014/09/25)

Pixiv

今後もちょこちょこ描き続ける予定なこともあってか、なんとなくPixivに登録してしまった。
暫く上手い人達にもみくちゃにされて来る。
http://pixiv.me/degarasu

(2014/09/22)

"Digital Cube Counter 3D"という名前は微妙かもなあと思い始めた。
まず長くてインパクトに欠けるし、
Counterというと英語圏の人には何かを数える意味合いが強いような気が。
バッテリーの残量はどちらかというと「測る」ものだしねぇ。
でも他に良い案が浮かばなかった…

ちなみに3Dとついてるのは描画がリアルタイムだというのもあるけど
90年代半ばの擬似3Dなゲームで流行っていた、とりあえずタイトル末尾に3Dをつけてみるノリ（Wolfenstein 3Dや、Duke Nukem 3Dなど）

(2014/09/21)

なんとなくustreamの配信を復活してみたが、特に何時から何時までという事はなく不定期で行く予定。たまにやってる位で。

モデルコンバータ

主にGUI部分のソースが汚いので設計が微妙な所も直しつつリファクタリング。
デザインパターンではないけどM-VC(Document-View)モデルを意識したりとか。
全部なのでしばらく時間かかりそう。時間かけてらんないけど。

グラデーション

鉛筆で描くグラデーションがワンパターンっていうか、あんまり綺麗に出来てない気がしたので
グラデーションの練習みたいな事してた。
プロは30段階位描けるらしいが、とりあえず自分はその半分でトライ。

結果。
一応定規でマス目作ってまず一番濃い色と一番薄い色、次にその中間、またその中間…という風に
やったつもりだけど最後の方とか隣と違いがよく分かんない感じだったんで
正味8段階といったとこか。修行が足りん。
上と下もちょっとムラができてるしねぇ…

そんなこんなで目立った進捗なし。

(2014/09/18)

Digital Cubeの現状

あの後もフリーズが見られなかったので全く手を触れずゲーム制作(というかC++の自作エンジン)に戻ってる。
実は幾つか拡張案を考えてみたり（色遷移のユーザー指定、バッテリー温度や電圧の表示、時計機能の追加等）
もしたんだけど…どれも微妙。
大体あのデザインが完成され過ぎててどこに追加の情報を表示しても蛇足に感じてしまう。
色遷移の編集にしても、自分が使う側に立って考えたら嬉しいというより面倒っていうか、別に要らない気がするし。
だったら見栄えのする色を最初からセットしておいてよ、という。

あとWifiやGPS、機内モードなんかの切り替えボタンもつければ便利だし
もしキューブと馴染むデザインが作れれば自分は標準の味気ない奴より使いたいなと思えるけど
当然要求するパーミッションが増える訳で、
バッテリーメーターの体であれもこれも要求すれば怪しいアプリと捉えられかねないし…どうなんだろう？

google playの方に評価付けてくれたり、コメントでも来れば「よっしゃ！」とかなって
頑張るんだろうけど。如何せんマイナーで。いや、宣伝も碌にしてないけどさ。
そんな感じ。

モデル

寄り道が多いとは言えなんだかんだでFBXに手を付けてから5ヶ月程経過。
流石に今月でモデルのエクスポートとインポート、そして表示が終わらなきゃカスだろうといった所。
なによりライブ壁紙で使いたいし、見栄えのするデモを作らねばならない諸処の事情もある。

とりあえずモデルの入出力はboost::serializationを使うので
それと関連したTreeNodeという、ツリー構造クラスのシリアライズ処理なんぞ書いていた。

絵

見ての通り前回からかなりの期間、練習をサボっている。
ヒョウモントカゲモドキの後も少しやってはいたが
下書きで放置してもう続きをやる気力が無いのとかあって悲しい状態に。

まぁ、かといってボケーッと突っ立っていても仕方ないので
例のAppWidgetが一段落した直後から新しくチマチマとやっている。
しかしだね。こんな作業の合間にテキトーにやってて上手くなるのかね？というのが最近の悩み。
（前に描いた奴のほうが上手く見えるあの現象）
あと測った訳じゃないが時間かかりまくり。写真の模写だったら下書きは30分くらいで済ませたい。

(2014/09/12)

作品を公開したら反応を毎日のようにチェックするのは誰しも経験あると思うのだけど
Digital Cubeで検索したら遂にトップになってた。
だから何だって感じではあるがもうアップデートの予定も無いし、後は落ちる一方なので記念に。
改めてAppWidgetは一旦完成としたい。

やはり一番でないと。

ちなみに何でこんなAppWidget如きに必死かと言うと
実は昔C++覚えたてでWin32APIを使って作ろうとし、挫折した事に対するリベンジだった。

(2014/09/11)

アップデートを繰り返してるせいか
当初はDigital Cubeで検索かけると40番目だったのが5番目に来てた（一時的）！これは勝てる気がしてきましたね。

今日も更新

珍しく止まってない。止まってないが・・アップデートかける予定。
連日アップデートなんてダルいと思うが600kb程度なんで許して欲しい。

前回、static変数もクリアされていて何も出来ないと言ってしまったけど何気ない時にふと思いつくもので
「AppWidgetManager(システムで用意されるSingletonなクラス)を通して何か取得出来るのでは？」と。
いや、以前にAppWidgetManagerのリファレンスは目を通していたものの、
API Levelが足りなかったり事前にXMLで設定した情報の取得だったりで「使えないな」と無視していたんだった。

調べた結果1つだけ、getAppWidgetIds()という関数が使えそうだなと。
文字通りWidgetProviderが受け持っているWidgetIdのリストを取得する代物で、
自分はいちいち自前でスリープ前にint配列を確保してバックアップしていた所をこれで代用できる。
むしろこっちの方が不意にWidgetを殺された時も対応できそうで良さげだ。

いやはや、勉強不足である。

ちなみにAPI Level11以上（Android 3.0以上）にすれば次のような魅力的な関数が使えるのだが・・
partiallyUpdateAppWidget() : Viewの部分的なアップデート
notifyAppWidgetViewDataChanged() : Viewの状態が更新されたら通知を受け取る
統計によるとまだ使用者が15%弱居るみたいだしとりあえずは2.3.3対象で行くか。

つーか3.0がマイナー過ぎて省かれてる・・

(2014/09/10)

Freeze, Fix, Test, Upload　略してFFTU。どうでもいい。
また修正版をアップしておいた。今回は気力が尽きたのでバグフィックスのみ。

ちょっと期待させておきながら相変わらず止まる。ちょこちょこスリープさせて確認してる時は大丈夫なのに
10時間位スリープさせて復帰させた後に固まってることが多い。
バッテリーの値はスリープ開始時からちょっと経過した辺りで止まってる。よくわからん。

デバッガの出番

そもそもなんで昨日思いつかなかったのかわからんけど、
ウィジェットたくさん出してすぐ固まる端末があるんだからデバッガ使えばいいじゃないか。
ってことで早速フリーズさせてログを見てみる。

結果から言うと、BroadcastReceiverに重い処理をさせすぎてAndroidに殺されていた。
一応その後は自動で復帰処理がかかるものの、static変数からなにから全部クリアされてる状態なのでこちらとしても何も出来ない。
要するにBroadcastReceiverで何秒もかかる処理をするなという事。

キューブを描画するルーチン(クラス)は勿論スレッドを作ってそこで実行しているのに何故？と思って調べたら
時間を食うInitialize関数をキューブのコンストラクタで呼んでしまっていて
これがAndroidのANR(Application not respond)規定時間を越えた瞬間死ぬと。
で、テストのためにAppWidgetを複数個置いてるとスリープからの復帰時にその個数分ダーっと初期化が走るわけだから
端末の処理が遅いほど、AppWidgetの個数が増えるほど死ぬ危険性が高まる。

一言で言えば実装ミスですなぁ・・・

長々とおいてアレだけどこれはスリープ復帰時に固まる話で
それとは別に動画などの重いアプリを動かしてると裏で死んでる事例があって・・
まぁ、ホームに7個とか8個とか置かなきゃ大丈夫っぽいんだけども。

(2014/09/09)

止まってた→直してみた→試す→アップする。の4段活用が暫く続きそう。

Androidでクラスのstatic変数がどの程度保持されるのか、ちょっと良くわからないが
リファレンスを読んでると「AppWidgetProviderは単なるReceiverである」と書いてある通り、
例えstaticといえど非finalな変数を持つべきではないという事かな。
はい、ガッツリ置いてました。とりあえずServiceの方へ移転。

もうひとつ。
通常、端末をアイドル状態で放置すると画面が消灯するがこの時即ロックされるのではなく
実際は5秒とか（これも設定によるけど）少し間がある。
で、消灯からロックまでの間に復帰されるとブロードキャストメッセージ：ACTION_USER_PRESENTが発生しない
従ってUSER_PRESENTのタイミングで描画開始するようなAppWidgetはアウツである。
ACTION_SCREEN_ONが望ましい。

バグフィックスばかりで頻繁にアップデートされたんじゃ使う人にとっちゃ全然面白くないんで
見た目の強化も図るのが自分のポリシー。
なので、キューブの回転速度、角度、投影方法なんかをもう少し原作に近づけてみた。
これまでなんとなく透視投影（遠近法）してたけどよくよく見てみたらあれ、正射影（遠くても見た目が変わらない）だったとか。
注意しないとわかんないけど、そんな感じで。

(2014/09/08)

折角「専用ページ」があるんだから、この話題はそっちでつらつら書けばいいのではという気がしてきた。

片方だけ

ASUS MemoPad HD7の方は幾つ置いてもフリーズしなくなったが、SO-03Dの方は相変わらず止まる。
止まる場合、ホームに5〜6個配置して10分放置すればほぼ確実に止まってくれて、そこは有難いかも。

困るのは前と挙動が異なっていて、
前は止まったAppWidgetを横目に新たなAppWidgetを置くとそっちは普通に動いてくれたけど
今度は駄目。それどころか端末を再起動しないと再び動いてくれない。
この点は更に悪化したとも言える。

う〜むなんだろう。更にメモリを節約すればいいのか、それとも別の原因があるのか・・・
あるとすればマルチスレッド関連だと思うので、今チェック中。

#追記

やはりフリーズはメモリ消費量が鍵だと考え、
色の遷移の計算を最初に一括計算しキャッシュしていたのを辞めてその都度計算するように変更。
これにより一回一回の描画が重くなったので前に「念の為」と入れていた再描画処理を削除。

という訳で昨日に引き続きコミットした。
明日の午前2時位にgoogle playの方に反映される予定。
これで最後になれば良いが。

(2014/09/07)

C++に戻る！と言いつつまた例のAppWidgetが止まってるのを発見してしまったので直す。
結局ゲームの方は2週間ぶりということもあり、そういやモーションのフォーマット考えてたなぁとか思い出しただけ。

メモリ上限

止まる原因の1つはメモリの使いすぎという事が判明。
やはりAndroid端末が搭載しているRAMとは別にAppWidgetなりのメモリ上限があるようで
バグ修正ついでにエフェクト増やそうとしたところで引っかかった。

メモリ上限を超えてリソース確保するとその場で固まる。
肝心の上限値は端末毎に（ホームアプリ毎に？）異なるようだが、それを調べる手段が見当たらない。
従って可能な限りメモリ使用量を減らすことが最善だろうか。
（エミュレーターだといくら確保しても何食わぬ顔で動くとこが、また・・）

ただ、自分の場合は幸い（？）Bitmapが大半を占めているので高画質が必要ない箇所の解像度を減らせばいい。
3Dでキューブをレンダリングする為のBitmapは既に64x64で若干ジャギが残ってるくらいなので変えられないが背景はぼやけていても問題ないだろう。
っていうかこれまでが無駄に高画質だった。
一枚で300x300も使ってて、これがRemoteViewsの関係で色の遷移数分（現状だと7枚）コピーされるもんだから無駄遣いも良い所である。
この背景を75x75と、大幅に減らすと初回の起動時間が5秒から0.5秒に減少。

ちなみにカウンターを含めた全体のイメージは441x512でこれが一番大きいのだけど手持ちの端末で確認した所、
ほぼドットバイドットで表示するにはやはりこれくらい必要かなぁと。
でもPngファイルなら20kb足らずで使うのも一枚だし、Bitmapクラスで加工するわけでもないので別にいいかな。
数字フォントは50x64、充電アイコンは31x48でこれらはシャープに表示したいので変更なし。

結局

フリーズした後にAppWidgetを削除すると必ず
”unfortunally, DC Counter has stopped.”みたいなエラーが出るのは分かってるけど
原因・・・いや、フリーズ自体は想定内なのだがそこから復帰できない理由は掴めぬまま。

こういう時にプロはデバッガをアタッチして調べるのかもしれないが、
リリースビルドで難読化してあるバージョンで発生したんでそのままでは無理そう。
確か難読化したソースを（予めシンボル情報を用意した上で）読めるようにする機能もあったはずだが
自分はそこまで使いこなせてない。

一番困るのは上記のリソース削減を行った後にフリーズが起こってないという。
そういやエミュレーターで止まったことは一度もないので
フリーズして復帰できないのはメモリの使いすぎでAppWidget全体が止まったからじゃないかな〜と勝手に納得している。

現状の見た目はこんな感じ。
カウンター外周の枠の色やキューブ周辺の”もや”を追加して原作に近づけたのと、キューブの背景解像度が落ちている。
数字の背景も直したんだけど・・・余程好きな人じゃないとわかんないだろう。

#追記

コミットした。反映される時間が前と同じならば明日の午前4時くらいにはダウンロードできるようになるだろう。
長々と続いてきたフリーズ問題、少なくとも手元の端末じゃそれは起きなくなってるが
三度目の正直となるか。
ついでに上記のような”もや”エフェクトと、キューブの揺らし方も原作に近づけた。

(2014/09/05)

アップデートした

まだ公開されて間もないけどアップデート。google playへはまた「数時間」かかるらしいが・・
内容は

ウィジェットをタップしたらバッテリーの使用状況Activityを開くようにした

単にAndroid標準のバッテリーサマリーを開くだけで、よくある機能。

描画フリーズ時の自動復帰

前に描画が止まる止まるどうしようと嘆いていた現象。
ふとしたきっかけでキューブの描画が一切行われなくなってしまい、それっきりになってしまう。
これはAndroidの仕様でViewがリセットされた事を検知できない為に起きる不具合なので
エレガントな解決策というものは無さそうだけど
流石に「再起動か、ウィジェットを設置しなおして下さい」というのもアレすぎるので
シンプルに
　2秒毎に”描画スレッドで描画が行われたか”をチェックし、1回もされてなければウィジェットを再起動
とした。
つまり、描画が止まってしまっても4秒以内に自動で復帰してくれる。筈

区切り

まだ凝ろうと思えば出来そうだけど一先ず自分が使う分には完成ということで
機能の追加は要望があればという形にする。
という訳でこれにて一見落着、C++のゲーム制作に戻る。

(2014/09/05)

反映された様で

https://play.google.com/store/apps/details?id=jp.gr.java_conf.dccounter
興味があればどうぞ。
なんとなくAndroid 2.3.3以上にしてしまったけど特にそういう機能は使ってないという。

ウィジェットの表示がフリーズしてうんともすんとも言わなくなってしまう時があるんだけど
たまーにしか発現しないので対処がわからん・・・

(2014/09/04)

公開の設定をした

やっとこさ公開の手順を踏んだ。
反映には数時間かかるらしくまだダウンロードできる段階には至ってない。
何かサポートのwebページが必須だというので仕方なくgoogle sitesで場所だけ確保した。
https://sites.google.com/site/ishikabesoft/dccounter
ロゴのサイズは厳密に指定されたサイズでないと受け付けないらしくその修正やら
紹介文の日本語と英語を用意したりで地味な所に時間がかかってしまった。
2回目以降は大丈夫だろうけど初めてですぐ公開したい場合はハマるなぁ、と。

一体全体何を作っていたかというと、こういう奴。