スマートフォンでDN2D使うと重い・・・

ND2DとBitmapでブロックの描写の検証してみた結果、次のようになりました。
使用した機種はN-06C (GPUはAMD製 Adreno 205で4100万ポリゴン/秒の性能)。

Bitmapを通常の描写で維持したもの
5000個 ： 25〜32fps

一つ一つにポリゴンを使い、GPUで書きだしたもの
5000個（10000Triangle）： errer
4000個（8000Triangle） ： 4fps
3000個（6000Triangle） ： 5fps
2000個（4000Triangle） ： 8fps
1000個（2000Triangle） ： 14fps

N-06CのGPU演算性能は、大体32000Triangle/s のようですね。
60fpsに収めるなら、533Triangleに収める必要が・・・。
思ったよりポリゴン数を使えないようです。

しかし、GPUだと全画面サイズのポリゴンを並べても
大きく速度が低下することがないということがわかりました。
また、タッチパネルを押した時の反応速度が低下しにくいようです。

※以下はタッチパネル操作時
Bitmapを通常の描写で維持したもの
5000個 ： 8fps

一つ一つにポリゴンを使い、GPUで書きだしたもの
5000個 ： errer
4000個 ： 4fps
3000個 ： 4fps
2000個 ： 6〜7fps
1000個 ： 14fps

細かい処理をCPUに任せて、大きなイメージの合成が必要な時だけ
GPUを使うのが最も効率がよさそうです。
また、最終的な表示としてただ書き出すだけでも効率が良くなりそう。

また、PCでもやってみたところ、表示限界は5000個程度でした。
PCでは、グラフィックボードの性能の限界が大きいものの、
AS3のメモリ256MB制限にひっかかり、つまずいたものと思います。

しかも、4000個で18fpsと、思いの外低速でした。
約14万4000Triangle/sという計算になりますね。
ND2Dは、PCでも1000オブジェクト程度までしか実用的ではないのですね・・・。

本格的な3Dのライブラリだと、18万ポリゴンを60Fps表示するものもあるので、
（と言うことは、なんと約1080万ポリゴン/秒！！ しかし、私のPCで使っているHD5670の性能は 7億7500万 ポリゴン/秒（Xbox360超）なので、著しく残念な結果ということに。）
今回検証に使ったND2D及びStage3Dの性能の向上を期待したいです。

壊リス・壊 を Flash Player 11.0 向けに魔改造・・・予定

いつも、スペックが低い端末の筆頭として、
スマートフォンで壊リス・壊の作動確認をしているのですが、
タッチパネルに触れたりすると、なかなかスムーズに動きません。

スマートフォン同士だと、RTMFPの通信が確実に通るので、
スマートフォンへの移植は必ずやっておきたいことなのですが、
現状では5人対戦でカクカク、二人対戦でも無理です。

そこで、次のAir や Flash Player11 の新しい機能である
Stage3D でさらなる高速化を目指すことにしました。

壊リス・壊の内部構造的には、

・グラフィック
　(表示サイド・バッファサイド)
・ゲーム本体
　(データサイド・イベントサイド・通信サイド)

の5つに分かれており、Stage3Dを適用する際は
表示サイドの完全入れ替えとバッファサイドの拡張で済みます。
高度な機能満載の ND2Dライブラリ に置き換えることでどうにかできそうです。

環境構築の一環として、ND2DのデモをAndroid向けに書きだしてみましたので、
Stage3D で 高速化の一歩 まずはライブラリ選び の記事をお読みください。

Stage3D で 高速化の一歩 まずはライブラリ選び

Flash Player 11のパブリッシュ設定を追加してから、
すっかり Stage3D の魅力に取りつかれてしまいました。

Stage3D って何？ って方はAdobeの資料を見るといいよ。

で、今作っている奴に一番合いそうなライブラリを探していたところ、
ND2Dというライブラリを発見しました。
ND2Dの公式サイトにデモとか色々載っています。

とりあえず、Android向けでも使えないかなと思いまして、
公式のデモを改造してAndoroid向けに仕立ててみました。

ND2D デモ (Android用改造済み)
※スペースの代わりにメニューボタンで切り替え出来ます。

なお、現状のAir for Androidでは、Stage3Dはサポートされていません。
よって、正式対応版である次のバージョンの Air 3.2（ベータ版）が必要です。

とりあえず、デモを走らせてパフォーマンスを確認している段階ですので、
使い勝手とか、苦労している点とか、設定方法とかは、後ほど。

Flash CS5 で Flash Player 11 向け swf を書き出すために。

Flash Player 11が登場してから結構立ちますが、


Flash Professional CS5 & CS5.5 に Flash Player 11 設定を追加する MXP - akihiro kamijo

というサイトを見つけました。

Stage3Dの高速性を取り入れたいと思っていたので、
ちょうど渡りに船です。ありがたいです。

ただ、これだけだと Air 3.0 向けに対応できません。
色々試した結果、CS5でもAir3.0を使う方法があったので、
"Flash CS5" で "Air 2.6 以降" を使うためのメモ
に、その方法の リンク と アドバイス を載せました。

"Flash CS5" で "Air 2.6 以降" を使うためのメモ

Adobe Flash CS5.5 Pro が出てから久しいですが、
CS6待ちなどで、Adobe Flash CS5 Pro から更新していない人も多いと思います。

僕も CS6待ち で CS5 → CS5.5 に更新していないのですが、
Stage3D を Andoroid端末 で使うために、Air 3.2 が必要になりました。
しかし、CS5では、Air 2.5 までしか使えません。

一般的なやり方としては、FlashDevelopなどの外部ツールに最新のFlexをあわせて、
Flash CS5 で作った MovieClip を用いて統合するなんてやり方が主流だったりします。
しかし、迷路のような入り組んだ構造のプロジェクトの場合、そうはいきません。

そこで、CS5でAirの最新版を使えないかとググっていたところ、
http://forum.starling-framework.org/topic/publish-for-mobile-from-cs5-ide
を経由して、
http://blog.prevail.co.nz/2011/06/21/overlaying-air2-7-in-flash-cs5/
というサイトを発見しました。

上のサイトでは、Air 2.7 を使う前提での解説になっていますが、
Air 2.7 の代わりに、 Air 3.2 を使ってもうまく作動します。
注意が必要なのは、設定ファイルも3.2向けに書きなおすことですね。


ただ、日本語版の場合、これらのやり方だけでは不十分で、
日本語版CS5.5体験版をインストールの上、
[en_US]のフォルダーではなく、[ja_JP]のフォルダに読み替えが必要です。

また、このサイトのやり方では、Air for Android の設定の一部が表示されません。
[C:\Program Files\Adobe\Adobe Flash CS5.5\ja_JP\Configuration]にある、
[Android]フォルダーもコピーしないと正常に使えません。

また、相性の問題で、過去に紹介した
CS5向けAir2.5 + Air for Android のベータ版拡張パック
を同時に使うことができません。

とりあえず、これで壊リス・壊をAndroid向けにリリースできそうです。

壊リス壊製作メモ + OpenRTMFP を試してみた。

お久しぶりです。風邪とか雪とか色々大変で、かなり間隔が開いてしまいました。
雪で大変ですが、そろそろ春の空気が感じられそう。（腰がいたいけど。）

只今、オフラインでのLineマラソンモードを実装中です。
ラインモードを実装すること自体は簡単なんだけど、
エフェクトを新しく用意しないといけないのが悩みの種。

あと、同時に通信対戦で快適な通信ができるように、
P2Pでの中継方法の他に新しい中継手段を考えています。

あと、P2Pの管理サーバーがオープンソースで出ているので、
http://poepoemix.blogspot.com/2011/10/rtmfp.html
を参考にCentOS上で作動させてみました。

しかし、なぜかリンク先の「5:CumulusServiceをコンパイル」で積みます。
（リンク先で紹介されているのが、古いバージョンだからでしょうか。）
とりあえず、エラーを読んで以下を修正してコンパイルに通してみました。

1.Luaが足りないようなので、Luaをyum等でインストールする。

2.ファイルを以下のように修正する。
<./sources/Script.cpp>
#include "lua5.1/lualib.h" → #include "lualib.h"

<./sources/Script.h>
#include "lua5.1/lua.h" → #include "lua.h"
#include "lua5.1/lauxlib.h" → #include "lauxlib.h"

<Makefile>
LIBS ?= -lCumulus -lPocoFoundation -lPocoXML -lPocoUtil -lPocoNet -lcrypto -lssl -llua5.1
↓
LIBS ?= -lCumulus -lPocoFoundation -lPocoXML -lPocoUtil -lPocoNet -lcrypto -lssl -llua -ldl

3.makeでコンパイル

しかし、起動したところ、共通ライブラリがみつからないと言われた。
調べてみて、パスが通っていなかったので、

export LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH"

にパスを通して起動したらすんなり起動してくれました。

試してみたところ、NetGroupも使えるみたいで、気に入りました。
自前でRTMFPのサーバーを用意する以外では、
Adobeから120万円のサーバーを買わないといけないので、
こういったものがフリーであるのはありがたいです。

コワリス壊制作メモ 11.12.31

今日までに完了した作業
1.対戦開始の両サイドへの実装
2.対戦中の処理をサーバー側に実装
3.対戦相手に自分のデータを送る処理の実装

現在の工程表
1.対戦中の処理をクライアントサイドに実装する（進行中）
2.対戦終了の処理を実装する（進行中）
3.観戦機能の実装（進行中）
4.加速装置の設置（サクっと実装したい）
5.ペナルティーの設置と拡充（実装待ち＆意見受け付けます）
6.ボーナスゲームの拡充（アイディア募集）
7.レートの実装および、賛否を議論して調整（基本まで実装）
8.さりげなく通信対戦のデータの流れを調整（いわゆるオーバーレイ処理）
9.動画を公開して客を呼び込み、公開試験（β版公開）

工程外
1.ブロックの数を圧倒的に増やす（続行中）
2.モバイル端末のタッチパネルやテンキーへの対応（挙動を検証中）

※1/5日書き込みなのに12/31の記事なのは仕様です。

とりあえず、通信対戦を[開始]できるようになりましたが、
[対戦中]の処理はあっても、[終了]の処理がまだありません。

また、サーバーの負荷の低減のためにP2Pでデータを送信していますが、
PCやルーターの設定によっては、相手に対戦中のデータが届きません。
（ゲームデータ以外は弾き、暗号化とIDで管理されているので安全です。）

そういう人のために、あとでサーバー経由の伝達ルートを作りますが、
相手のプレイ画面が届かない場合があるのは現状では正常です。
しかし、発生したPCの環境を報告してくれるとありがたいです。

後、ボーナスゲームの種類の増設などに対するコメントを頂きました。
現状、ボーナスゲームの増設ではレトロゲーを盛り込みたいと思っていますので、
好きなレトロゲーを大人の事情が邪魔しない程度におすすめしてくれるとありがたいです。

新年あけましておめでとうございます〜

先年中は大変お世話になりましたm(´・ω・｀)m。
本年もよろしくお願いいたしますm(　_　_　)m。

大晦日から2徹で大変でした。
実装を限界までやった後に、年越しの儀式と挨拶回り。
その後、盆と正月にしか集まらない家族で出かけてきました。

その眠い目でヤフオクで怪しい商品を間違って落札してしまったり、
中国製タブレット端末を作動検証用に買おうか悩んだり、
年明けから散々でしたね〜。

年末年始って、忙しいね〜w！

コワリス壊制作メモ 11.12.29

今日までに完了した作業
1.ブロックを17個ゾーンまで実装（約15万種類）
2.ブロック選定バグの修正
3.ブロックの種類の増加によるバランス調整
4.ブロックの展開方法を変え、高速に展開するようにした。
5.対戦開始処理のサーバーサイドへの実装

現在の工程表
1.ブロックの数を圧倒的に増やす（続行中）
2.観戦機能のサーバーサイドの実装（進行中）
3.対戦中の処理をサーバーサイドに実装する（進行中）
4.対戦終了の処理をサーバーサイドに実装する（進行中）
5.対戦の種類別の処理をクライアントサイドに実装（整理中）
6.(5)に伴い、サーバーサイドに制御の記述を加える。
7.加速装置の設置
8.ペナルティーの設置と拡充
9.ボーナスゲームの拡充
10.レートの実装および、賛否を議論して調整
11.公開試験（β版公開）


ブロックの数を増やしたので、ライブラリの展開が遅くメモリも大量に消費して、
パフォーマンスを低下させ、スマートフォンで開けなくなっていました。

そこで、20万行超えたブロックのライブラリを凝縮した1つのファイルにすることで、
パフォーマンスを保ちながら、ブロックの種類を増やすことにしました。
行数が一気に29万行減り、3万行のプロジェクトに逆戻りですが、
実際には中間処理で発生するコードが多く、減った気がしません・・・。

スマートフォンに対応させる方向で工程表外のことが進んでいます。
もちろん、対戦の方も実装中（というかデバッグ中）ですよ〜。
考えるのが楽しいけど、いつまでもこのままとは言っていられない。
やはり、結果は出さないといけないし・・・。

Flash CS5（CS5.5） でAndroid端末への.apk転送が上手くいかない時に見るメモ

Flash CS5.5 で、ドライバを入れなおしてもスマートフォンに転送できない人や、
Flash CS5 でAndoroid向けAir書き出し機能を追加する
flashpro_extensionforair_p2_112210.zxp を導入し、
コンパイルには成功したけど、転送で積んだ人用のメモです。

コケる原因で一番多いのが、ドライバとPCリンクモードです。
PCにドライバが入っていない場合や、正しくない場合は何をしてもダメです。
素直に、端末用のドライバをメーカーからダウンロードしましょう。
また、多くの機種ではデバッグモードよりもPCリンクモードが優先されるため、
端末のPCリンクモードを切ってください。それでも転送できない場合は次です。


ドライバも正しく、PCリンクモードでもない場合、ADBが古いのが原因です。
さて、この記事の本題、ADBのバージョンを新しくする方法です。

FlashCS5では、スマートフォンの機種が新しい場合、上手く実機に転送できない事が多いです。
Flash CS5のリモートデバッグでは、ADBを使ってファイルを転送してデバッグしますが、
Flash CS5に載っているADBは2010年11月のもので、新しい端末には対応していません。
これらは、ADBを新しくすることで解決します。

最新のADBは、最新のAndroid SDKに付属しています。
ここなどを参考にAndroid SDKを導入してみるといいです。
なお、Android SDKには端末エミュレーターが付いているので、導入済みの人もいると思います。

Android SDKをインストールできたら、次の作業です。
Android SDKをインストールしたフォルダから、
...\android-sdk-windows\platform-tools
の位置にADBの本体とDLLがあります。

ファイル名は次の通り。
adb.exe
AdbWinApi.dll
AdbWinUsbApi.dll

これら3つのファイルをCS5の場合は、
C:\Program Files\Adobe\Adobe Flash CS5\Android\tools
また、CS5.5の場合は、
C:\Program Files\Adobe\Adobe Flash CS5.5\AIR2.6\lib\android\bin
にあるファイルに上書きしてください。
（元からあったファイルは、バックアップを取っておいてください。）
これで、デバイスは認識するのに転送できない状態を回避できます。

なお、新しいADBはサイズも小さく、色々高性能になっているようなので、
認識しなくても置き換える価値はあると思います。

以上、メモでした。