ハマケン100%開発: 7月 2011

2011年7月29日金曜日

ズッコケGuys リリースされました！

ズッコケGuys が、App Storeにてお目見えしました。

iPhone、iPad 両対応のユニバーサルアプリです。
Flash CS5.5 の AIR for iOS を使用して作ったアプリです。

ぜひダウンロードのほど、よろしくお願いします。
最初の10万本は無料です。(遠い目標だな〜笑)

今回、初の AIR for iOS アプリとなりましたが、まだ、詰めが甘いところがありました。
以下の対応言語のところなんですけど、チェコ語とか、ポルトガル語、スウェーデン語だなんて、ずらりと列記されてますが、言語リソースとして入ってるのは英語と日本語だけ。(笑)
何でこんなことになってるのか、今のところまだ分かりません。Flash CS5.5のパブリッシュで、デフォルトで設定されてるのでしょうか？

それから、チェコ語でズッコケGuysって、どう翻訳すればいいんでしょうね？(笑)
どなたか教えて下さい。

何はともあれ、念願かなってリリースされましたので、とりあえずはメデタシメデタシです。

2011年7月28日木曜日

adlプレビュー時の起動時のStageOrientation

Flash CS5.5でデバイスの回転に対応したiOSアプリのムービープレビューでひっかかったところがあったので書いておきます。

上記のように Player に AIR for iOS を指定しておくと、ムービープレビューはFlash Player上で行われるのではなく、adlというプログラム上で行われます。adlはモバイルデバイスの90°単位の回転に対応しています。
しかしFlash CS5.5から実行した時に、少し連携がとれてない所があるような気がしました。

AIR for iOS 設定パネルの「起動時の縦横比」を横長モードにした時に、adlでは縦長モードとして起動しているような気がします。ムービープレビューした時に、一見、正常に動作していると思っても、回転コマンドを送ってみると整合性が取られていない事に気づかされました。

何か他に見落としている所があるかもしれませんが、ムービープレビューでのデバッグが面倒くさいので、基本、縦長モードにしておくことにしました。
ただし、デバイスに転送した時は正常に動作するので、リリース用パブリッシュをする時に変更するのもありかもしれません。

2011年7月27日水曜日

AIR 2.6とAIR 2.7の描画速度比較

AIR for iOSで実行する時のグラフィック描画速度を、開発中のアプリ「ネコライフ時計 for iPad(仮)」で計測してみました。

アプリは最大30フレームで動作するように設定しています。計測デバイスは初代iPadです。
結果は以下のようになりました。

計測条件	フレーム数
AIR 2.6 + CPUレンダリング + 非ビットマップ	6 frame
AIR 2.6 + CPUレンダリング + ビットマップ	6 frame
AIR 2.6 + GPUレンダリング + 非ビットマップ	3 frame
AIR 2.6 + GPUレンダリング + ビットマップ	23 frame
AIR 2.7 + CPUレンダリング + 非ビットマップ	13 frame
AIR 2.7 + CPUレンダリング + ビットマップ	13 frame
AIR 2.7 + GPUレンダリング + 非ビットマップ	3 frame
AIR 2.7 + GPUレンダリング + ビットマップ	23 frame

非ビットマップというのは、ネコなどのムービークリップをシェイプのまま使用しているという意味です。
ビットマップは全て実行時にビットマップにする方法をとっています。
ActionScript3で、以下のように記述しています。

displayobject.cacheAsBitmap = true;
displayobject.cacheAsBitmapMatrix = new Matrix();

個人的にうっかりしていたのは、GPUレンダリングモード時でもAIR 2.7の描画速度最適化の恩恵が得られると思っていたのですが、計測結果が表すようにそうではありませんでした。
しっかり公式発表にもCPUレンダリングモード時と書いてありました。

計測結果を見ると、ビットマップ化してGPUでレンダリングするのが一番速いのがわかります。
このことだけをとってみれば、AIR 2.6とAIR 2.7の違いは無いようです。
さて、シェイプタイプのムービークリップをビットマップ化するタイミングですが、今回の実験のように実行時に行うと、レンダリングの結果がCPUモードとGPUモード時で結構変わってしまうことが分かりました。

CPUモードで実行時ビットマップレンダリング

GPUモードで実行時ビットマップレンダリング

ステージのレンダリングクオリティはどちらともデフォルトの設定のままなので、以下の設定と同等だと思われます。

stage.quality = StageQuality.MEDIUM;

この事を踏まえると、ビットマップ化は実行時にするのでは無く、パブリッシュ時に行ってしまう方が、映像のクオリティ的には良いと思われます。

2011年7月26日火曜日

AIR 2.7でiOSアプリをパブリッシュ

AIR 2.7が出てから１ヶ月ほどが経ちます。
AIR 2.7で一番気になっていたのは、iOS上の描画機能最適化です。何と言っても描画速度が4倍になったということなんで、これは期待せずにはいられません。既にYouTubeなどでも描画速度比較デモが披露されており、それを見る限りでは期待しても良さそうです。

本来は、Flash CS5.5でAIR 2.7対応iOSアプリがパブリッシュできるようになってから試すつもりでしたが、新プロジェクトの"ネコライフ時計 for iPad(仮)"の開発中に、やっぱり動作が重くて厳しいよ。という事になり、急遽、AIR 2.7 SDKをインストールしました。

ネコライフ時計 for iPad(仮) 只今開発中！

僕はFlash CS5.5で開発を行ってSWFを書き出しているので、その辺りの連携も含めて書いてみたいと思います。

AIR SDKのダウンロード
http://www.adobe.com/jp/products/air/sdk/
圧縮ファイルを展開して、適当なフォルダに入れる
展開したフォルダの中にあるbinフォルダにパスを通す
(この後に使うadtコマンドをフルパスなどで指定するならパスは通さなくても良いです。僕は面倒なんでそうしてます)
Flash CS5.5で適当なアプリをAIR for iOSでパブリッシュ
これでSWFファイルと、(flaファイル名)-app.xmlファイルが生成されます
(flaファイル名)-app.xmlファイルをテキストエディタで開き
<application xmlns="http://ns.adobe.com/air/application/2.6">を
<application xmlns="http://ns.adobe.com/air/application/2.7">と書き換えます。
xmlのファイル名を(flaファイル名)-app-2.7.xmlとかに変更して保存します。(Flash CS5.5で2.6に書き戻される可能性があるので)
ターミナルを起動して、SWFファイルのあるフォルダへ移動します
adtコマンドでパブリッシュ
ターミナルコマンドは例えば以下のようになります。adtコマンドへパスが通ってない場合は、フルパスか相対パスにして下さい。証明書とそのパスワード、プロビジョニングプロファイルはご自身のものを指定して下さい。
adt -package -target ipa-test -keystore <iOS証明書(p12)ファイル> -storetype pkcs12 -storepass <証明書パスワード> -provisioning-profile <プロビジョニングプロファイル> NekoLife.ipa NekoLife-app-2.7.xml NekoLife.swf

上記の方法で ipaファイルが生成されますので、これをiTunesを使ってデバイスへ転送します。

-targetオプションはipa-testの他に以下のものが設定できるようです。
参考サイト:http://www.slideshare.net/ton1517/air27air-for-ios-8569409

ipa-ad-hoc
アドホック用
ipa-app-store
App Store配布用
ipa-debug
デバッグ情報を含むパッケージ
ipa-test
最適化やデバッグ情報を含まずにコンパイルされたパッケージ
ipa-debug-interpreter
ipa-debugと同等。コンパイル時間が短くなる。コードの実行が遅い。
ipa-test-interpreter
ipa-testと同等。コンパイル時間が短くなる。コードの実行が遅い。

2011年7月25日月曜日

cocos2dの勉強

遅ればせながら cocos2dを少しづつ触り始めていますが、なんというか、やはり楽です！

cocos2dの魅力は、iPhoneゲーム開発者を一生懸命サポートしようとする考え方が、フレームワーク開発者やコミュニティに溢れているようなところでしょうか。

勉強には、cocos2dで作る iPhone＆iPadゲームプログラミングを使用しています。

只今、第４章を終了したところです。
この章で紹介されていた Fontのビットマップ化ツール Hiero と、CCLabelBMFont クラスの組み合わせはとても便利で気に入りました。

Hieroは以下のページからダウンロードできます。
JavaアプリケーションなのでMac、Win両方で大丈夫でしょう。
http://slick.cokeandcode.com/

ただ Hiero で出力されるPNGファイルが、OpenGLに準拠しているためか、上下逆さになっているので元に戻してやる必要があるようです。
こんな風になってるので

元に戻してやります。地味にめんどうなんですけど。(笑)

AIR for iOS が AIR 3 になるまでは、cocos2dを積極的に利用していく機会が多くなるかもしれません。

2011年7月22日金曜日

Mac OS X Lionでのスクリーンセーバー状況

Mac OS X Lionが発売されたようです。
僕はまだOSアップグレードしていませんが、「ふわぽかタウンスクリーンセーバー」を利用してくれている方から、さっそく動作報告を頂きました。

その方によりますと「Lion上でスクリーンセーバーの動きが鈍くなっている」とのことでした。
この事が何をあらわすのか、現段階でははっきり分かりませんが、OSが重くなっているのか、Macでスクリーンセーバーが市民権を取り戻すのはいつなのかで書きましたが、スクリーンセーバー起動時のパワーセービングがより強化された可能性はあります。

後者だとすると、スクリーンセーバーでは、あまり複雑なことはするなというのがAppleの方針なのかもしれません。
ここにもECO化の波が？

AIR for iOSでアプリ名をローカライズ

急激に寒くなってきたので、ちょっと体調を崩してしまいました。
みなさんもお気をつけて。

ズッコケ４人あらため、ズッコケGuysをApp storeに申請しました。
レーティングの点で不安要素がちょっとあるので、リジェクトされなければいいなぁ。

今回は、アプリ名を英語と日本語で分けたかったので、その辺りの事を調べました。
AIR for iOSでアプリ名をローカライズするには、(flaファイル名)-app.xmlという設定ファイルをテキストエディタなどでいじれば可能です。

<name>アプリ名</name>
<!-- To localize the name, use the following format for the name element.
<name>
  <text xml:lang="en">English App name goes here</text>
  <text xml:lang="fr">French App name goes here</text>
  <text xml:lang="ja">Japanese App name goes here</text>
</name>
-->

デフォルトで上記のように記述されている箇所があると思います。
もうお分かりのように、上記のコメントを外して必要事項を書き込みます。
ちなみに、enは英語、frはフランス語、jaは日本語です。その他の国コードもありますので、それぞれ必要な国を追加してください。例えばドイツならdeです。
ズッコケGuysの場合は下のようにしました。

<name>
  <text xml:lang="en">PratfallGuys</text>
  <text xml:lang="ja">ズッコケGuys</text>
</name>

注意点は一番最初に記述されていた <name>アプリ名</name> の部分は削除することでしょうか。これがあるとパブリッシュ時にエラーがでます。
しかし悩ましいことにこれを削除すると、Flash CS5.5の「AIR for iOS 設定」パネルのアプリケーション名が空欄になってしまいます。ですがこれはフェイクで、ちゃんとアプリ名は保持されているので安心してください。

最後にズッコケGuysをiPadで実行させたムービーをご紹介。
演奏されているBGMは、Zukkoke Guys Foreverというオリジナル曲です。(笑)
このあたりの話しは、またそのうちに。

2011年7月19日火曜日

AIR for iPad

AIR for iOSを使う利点の一つとして、画面サイズの違いを吸収してくれるというところがあります。AIR for iOSというか、Flashの利点なのですけどね。
ブラウザにSWFファイルをドラッグアンドドロップしてから、ブラウザの大きさや縦横比を変えた時のFlashの見え方を思い出して頂ければ分かりやすいと思います。

iPhone/iPadの解像度は以下のようになっています。

iPhone4以前・・・320x480
iPhone4・・・・・640x960 (Retina対応ソフト時)
iPad/iPad2 ・・・768x1024

iPhoneだけで考えれば縦横比は一緒なんですが、iPadは1:1.333と縦横比が変わってしまいます。ネイティブアプリ開発時は、フレームワークのUIだけを使っていれば、それほど困ることは無いかと思いますが、OpenGLを使っている2Dゲームアプリの場合だと、マルチ解像度対応は意外と面倒くさいので、フレームワークやライブラリやらがスクリーン解像度の違いを吸収してくれるととても楽です。

ズッコケ４人もiPadに対応させてみました。
Flashの威力のおかげで、スクリーンの上下に黒帯マスクを追加するだけで対応は済みました。
あと、iPhone4よりも、若干iPadの方がフレームレートが上がりました。うれし〜。

ベクタータイプのムービークリップをビットマップ化するタイミングには注意が必要です。
パブリッシュする前にビットマップ化してしまうと、当然ながらその解像度で固定されてしまうので、大きなスクリーンで表示すると、引き伸ばされて画像が汚くなってしまう可能性があります。

ベクターグラフィックをビットマップ化するのは、ActionScriptからも指定できます。
これだと実行時にビットマップ化されて便利なのですが、デバイスによってその効果の程はまちまちなようです。
PCでは効果が無いというか、逆に遅くなった体験が過去にあります。

displayObject.cacheAsBitmap = true; 
displayObject.cacheAsBitmapMatrix = new Matrix();

cacheAsBitmap はビットマップ化するよ、というフラグです。
cacheAsBitmapMatrix はビットマップ化(レンダリング)する時の基準となる変換マトリクスで、通常は上記のように単位マトリクスを指定するようです。

詳しくは Adobe Helpの AIRでキャッシュされたビットマップの変換マトリクスをご覧になると良いと思います。

2011年7月16日土曜日

ズッコケ４人 for iPhone 鋭意製作中

いやー、今日も暑い。
超絶な太陽ビームが降り注ぐなか、お年寄りが杖を突きながら外を歩いてました。
全アスファルトをひっペがしたい気分です。

ズッコケ４人 for iPhone 鋭意製作中です。
最初は動作テストで始めたプロジェクトでしたが、やり始めるとつい熱中してしまいます。
今日はずいぶん作業を進めることができました。
Flashだとアートワークをしながらの開発も、結果がすぐプレビューできるので楽しいです。

幅広い年齢層にプレイしてもらうため、アルコール表現を極力抑えております。
無駄な努力か…(笑)

2011年7月15日金曜日

AIR for iOSでアプリを完全に終了させる方法

ズッコケ4人のオープニング画面は、なんとなくこんな感じに…。
タイトルに Flash CS4から実装された3D回転を使ってみました。3D効果でなんとか高級っぽく！って思ったけど、なってねぇ〜！

iOS4になってから、サードパーティアプリにもマルチタスク化の対応が求められるようになりました。終了ボタンが押された時の仕様を、プロセス終了 or サスペンド処理のどちらかにする必要があります。たいていのアプリがプロセス終了を選択していると思います。

なんでか、AIR for iOSでアプリをパブリッシュすると、デフォルトではサスペンドするようになっています。これだと知らず知らずのうちに、多くのリソースがメモリに残ってしまうアプリを量産してしまう可能性があります。
これをスイッチひとつでプロセス終了仕様に変更したい！のですが、世の中そうなってないのが悲しいところです。
修正には、XMLファイルに設定を追記する必要があります。
FlashからiOSアプリをパブリッシュするのには、SWFファイルと、各種設定用のXMLファイルが必要となります。XMLファイルは flaファイル名-app.xml となって自動生成されます。このXMLをテキストエディタなどで開きます。

<InfoAdditions>
 <![CDATA[
  <key>UIDeviceFamily</key><array><string>1</string></array>
 ]]>
</InfoAdditions>

中にこんなような記述があると思いますが、CDATAの中に次のように新しい設定を加えます。

<InfoAdditions>
 <![CDATA[
  <key>UIDeviceFamily</key><array><string>1</string></array>
  <key>UIApplicationExitsOnSuspend</key><true/>
 ]]>
</InfoAdditions>

ここで注意して欲しいのが、Adobeのヘルプには

<key>UIApplicationExitsOnSuspend</key><string>YES</string>

と書いてありますが、これだと何も変化が無かったので注意してください。
正解の情報は書籍 Flash CS5.5ではじめるiPhone/Androidアプリ開発入門に書いてありました。

2011年7月14日木曜日

Package for iPhoneの可能性

FlashをCS3から一気にCS5.5へバージョンアップしました。

色々気になっていた機能がありますが、やっぱり一番試したかったのが Package for iPhone(AIR for iOS)です。
iPhone上で動くアプリをFlashで作っちゃおうというものです。
プロジェクトをほとんど変更なしに、Android用アプリとしてもパブリッシュできるそうで、Apple的には認めたくないでしょうが、こういったオーサリングソフトやフレームワークが、今後ますます求められてくるのでしょう。

とりあえず今まで作ったFlashがiPhone上でどれだけの速度、クオリティで動かせるのかを試してみました。

試したのはズッコケ4人という拙作Flash。よっぱらい企業戦士たちに、お疲れ様と感謝の気持ちを込めて作ったアプリです…。物理演算ライブラリ Box2Dを使っており、CPUパワーもかなり使います。

まずは全てデフォルトでパブリッシュし、iPhone4上でテストしてみましたが、、、

まったくアニメーションしない…。あっ！よく見ると少しずつ動いてる…。というような、あまりにも残念な結果になりました。

しかし、グラフィックのレンダリングにGPUを使わせるというオプションがあり、かつシェイプ(ベクター)グラフィックをすべてビットマップにして書きだすと高速化させることができるとの事で、それをやってみると、なるほど秒間10フレームぐらいまで高速化できました。

また、ステージのレンダリングクオリティを
stage.quality = StageQuality.MEDIUM;
から
stage.quality = StageQuality.LOW;
に変更すると、シェイプグラフィックのレンダリングが汚くなりますが、高速化できるようです。この品質はビットマップグラフィックには影響しないようです。

その後、Box2Dの演算の精度を落としたり調整を繰り返して、だいたい秒間15フレームまで出るようになりました。PC上では秒間30フレームで動かしていたので、まだまだ、もっさりした速度ですが、使いようによっては使えるかな？という感じにはなりました。
ズッコケ4人は、何かもうちょっと付け足して、iPhone用アプリとして申請してみる予定です。

AIR for iOSでは、iAdやGame Center、In App Purchaseの対応がどうなるのか、まだまだ不安な面があります。
しかし当面、拡張は考えていない簡単なアプリを作るには、便利なオーサリングツールであることは確かです。今までつくってきたFlashアプリが、ほとんど変更もなしにスマートフォン用アプリに変身させる事ができるかもしれません。一度試してみる価値はあるかもしれませんよ。

2011年7月13日水曜日

Macでスクリーンセーバーが市民権を取り戻すのはいつなのか

僕はMac,Windows用スクリーンセーバーを長らく開発＆公開してきましたが、Macのスクリーンセーバー事情には、このところ芳しく感じておりません。

スクリーンセーバー開発において、過去メインにつかってきたツールはFlashでした。
作成したSWFファイルをMac、Windows用スクリーンセーバーに変換してくれる、fla:ver というツールのLiteバージョンが無料使用でき、その性能も高かったのです。

しかしMac OS Xが、Snow Leopardになってから状況は変わりました。スクリーンセーバー上で走るFlashの動作が、著しく速度低下を起こすようになりました。この状況は、fla:ver Liteバージョンで作成したMac用スクリーンセーバー、CocoaのWebViewを使ってFlashを再生させた場合、両方とも同じでした。WebViewに至っては、スクリーンセーバーモジュール上でのみFlashの動作が遅くなった覚えがあります。(この辺、記憶があやふやですが)

これはAppleがFlashを嫌っていることに関係があるのでしょうか？
なぜならこの状況はAppleが提供する Quartz Composerでも起こっているからです。
Quartz Composer上でコンポジションをフルスクリーンで動作させる時よりも、スクリーンセーバーモジュールとしてフルスクリーンで動作させた時の方が動作がカクつきます。

この状況を鑑みて、Mac OS X Snow Leopardのスクリーンセーバー起動時は、CPUなどのパワーセービングを行っているのではないかと推測します。(いや、真実のほどはわかりませんが…)
確かにSnow Leopard以前のOS上で、重い処理のスクリーンセーバーが起動すると、CPUファンがフル回転を始めて、とてもエレガントとは言いかねる状況が多々起こりました。
しかも、パソコンを使用していない時の方が電力を使う、というのも変な話しなので、これは致し方ないことなのかもしれません。

しかし僕としては、こういうパソコンを使っていない時こそ、もっといろいろ楽しいことをパソコンから見せることができるのにと思っています。
コーヒー飲んで休憩してる時、部屋にあるパソコンから何やら楽しげな映像や音が飛び出してきたら、思わず仕事も忘れてホッとしますよね。(笑)
さて、近々発売となる Lionはどうなるでしょうか？