VG-EngineのJava部分の描画処理をSurfaceView+CanvasからOpenGL（GLSurfaceView+GL10）に変更したところ、処理性能が大分落ちてしまった問題が直りつつあります・・・ですが、今一歩。。。
ポイントとなるonDrawFrameの処理は以下のような感じ。
public void onDrawFrame(GL10 gl10) {
// VG-Engineの描画処理を呼び出す
int rc=SHOT04.setVram(vram);
if(0!=rc) {
System.exit(0);
}
// VRAMの内容をテクスチャ領域へ転送
// GLUtils.texSubImage2D(GL10.GL_TEXTURE_2D,0,0,0,vram);
gl10.glTexSubImage2D(GL10.GL_TEXTURE_2D,0,0,0
,TXSIZE
,YSIZE
,GL10.GL_RGB
,GL10.GL_UNSIGNED_SHORT_5_6_5
,vbuf
);
// 描画
drawUv.put(vramPositions);
drawUv.position(0);
gl10.glEnableClientState(GL10.GL_VERTEX_ARRAY);
gl10.glVertexPointer(3, GL10.GL_FLOAT, 0, drawUv);
gl10.glDrawArrays(GL10.GL_TRIANGLE_STRIP, 0, 4);
} |
最初のSHOT04.setVramというのは、VG-Engine（エミュレータ）の中核描画ルーチンです。
従来、引数に渡しているvramはBitmapクラス（AndroidBitmap）でしたが、byte配列に変更。
この部分で、仮想VRAM（240x320pixel）の描画処理を行います。
AndroidBitmapのlock/unlockが無くなった分、高速になったかも。
ただ、ポイントはそこではないです。
ポイントは、「
VRAMの内容をテクスチャ領域へ転送」というコメントのところです。
この部分を、
GLUtils.texSubImage2Dから
GL10.glTexSubImage2Dに変更しました。
GLUtils.texSubImage2Dの場合、AndroidBitmapを引数に渡します。
しかし、転送するバッファサイズを指定できないから、常に全体を転送する無駄が生じます。
OpenGLの仕様上、テクスチャ画像の辺の長さが2のn乗でなければならないので、VG-EngineのVRAM仕様（QVGA=240x320）の場合、AndroidBitmapのサイズは256x512pixelという具合になり、無駄なデータ転送が発生する訳です。
GL10.glTexSubImage2Dの場合、テクスチャバッファに転送するバッファの幅と高さ情報を指定できるので、転送量を256x320にすることが可能になります。（ちなみに横方向は240にすると危なそうなので、256のままにしておきました）
これにより、転送量を262,144byteから、163,840byteに削減できます。
ほぼ半分程度の削減になりますね。（
47.5%の削減）
OpenGL内部でのバッファ⇒テクスチの変換処理が恐ろしく遅いので、この削減効果は極めて大きいです。
ちなみに、テクスチャやテクスチャの表示位置を設定する処理は、全てonSurfaceChangedで纏めてやってます。
つまり、変換イベントを検出しない限り、1回ポッキリ。
こうすることで、バッファリング演算の処理回数を大幅に削減できます。
大幅っていっても１テクスチャのみだから高が知れてますが。
描画時の頂点バッファ演算（２ポリゴン分）は削れませんが。（この部分も最適化の余地があります）
なお、サーフェースのクリア処理（glClearとか）は大して重くないけど、やる意味が無いから、やってません。
（テクスチャは画面全体のVRAMが1枚のみだから、こういうやり方でOK）
しかし、このやり方でやっても
52～58fps程度しか出ない。（IdeaPadA1の場合）
やはり、常識的に考えて、テクスチャの書き換えというのは重過ぎる。。。
（当然ながら、ボトルネックは
glTexSubImage2Dです）
ちなみに、上記はBVQ（
Basic Vert Quads）という、割とオーソドックスな手法です。
DTE（Draw Texture Extension）の方が高速という噂があるので、DTEも試したのですが、結果は同程度。
（性能が同程度なら、オーソドックスな手法の方が良かろうと思います）
やはり、
テクスチャの書き換えによる描画という手法自体が鬼門ですねぇ・・・。
まぁ、最初から知っていたことですが。
（知っていたから、当初Canvasを使っていた訳で）
surface lockをサポートしている分、OpenGLよりはDirect3Dの方が2D向きです。
何故、OpenGLはsurface lockをサポートしていないのやら・・・
3D onlyのゲームでも普通に要ると思うのですが。
半分、諦めの境地です。
ですが、諦めるのは
まだ早い。
「思い切って、フルネイティブ（NativeActivity）にしてしまえばどうだろう？」というのも、無くは無いです。
当初、Android特有の拡張機能を取り込むのに不便だから避けてましたが、必要になるとすれば広告（アフィリエイト）や何らかの通信サービスを入れる時ぐらいだろうし、そういうものを実装するつもりは今の所無いので。（でも、後からやりたくなったら困るから、中々踏み切れない）
追記
上記のonDrawFrameの処理時間を測定してみたところ、だいたい平均で9ms～10msぐらい。
個別に測定してみたところ、
・仮想VRAM作成（setVram）が3～6msぐらい（ゲーム本編の処理量による）
・テクスチャ作成’（glTexSubImage2D）が5～15msぐらい（平均すると7ぐらい）
・描画が1～2msぐらい
たぶん、これが限界性能なのかも。
もうちょっと最適化余地を探ってみますが。
あとは、JavaVM（
ダルビッシュでしたっけ？）とかAndroid側の制御や、VGSの処理（OpenSL）の制御やらが色々絡んでって感じかなぁ・・・ただ、VGSは別スレッドの筈だから、そんな大したものではないです。なので、やはりNativeActivity化が一番優良の策なのかも。。。
キツイなぁ。
追記2
とりあえず、NativeActivity化する前に、onDrawFrameの処理（全部）をJNIで実行する形に改造。
↓こんな感じ
@Override
public void onDrawFrame(GL10 gl10) {
// VG-Engineの処理を呼び出す
if(0!=SHOT04.setVram(gl10)) {
System.exit(0); // Exitボタンが押された
}
} |
まぁ、Javaで書く意味は無いですからねぇ。
頂点座標についても、onSurfaceChangedで、Cのバッファへコピーし、Cで作成。
ループ処理中のJavaからのデータ受け渡しは一切無いです。
こうすれば、NativeActivityで実装するのとほぼ同等性能だと思います。
たしかに、少しばかり速くなりました。
遅いタブレットマシンでだいたい55～58fpsぐらい。
Razrならほぼ60fps。
う～ん・・・今一歩です。
やっぱり、NativeActivityにするしか無いかなぁ・・・
追記3
まぁ、追記2のコードでダメだったということは、このままNativeActivity化しても効果はほぼ無いでしょう。
Javaコードは、タッチ等のイベント処理とonDrawFrameしか走らないので。
なので、圧縮テクスチャを利用してみようと思います。
一般論で、「圧縮」というと遅そうなイメージですが。
ただ、OpenGLの世界では、
圧縮＝色のビットレートを落とすことという意味らしい。
まぁ、圧縮であることには違いません。
データ転送量が減るから、圧縮した方が高速だということです。
16bitカラーから8bitカラーに変更した場合、
glTexSubImage2Dの転送量が次のようになります。
・16bitカラーの場合 = 240×320×2 = 153,600byte
・8bitカラーの場合 = 256色×3byte＋240×320×1byte = 77,568byte
VGEの仮想ハードウェアの色表示性能は8bit（256色）なので、表現性に劣化は生じません。
（VGEのハードスペックを設計した時、8bitカラーを採用しておいて本当に良かった・・・）
表現性に劣化が生じずに転送量を1/2にできるというのは美味しすぎる。
つまり、これをやらない手はないです！
追記4
ほぼ、チェックメイトになりました・・・
圧縮したテクスチャ情報を送信する場合
・
glCompressedTexImage2D または
・glCompressedTexSubImage2D を使います。
glCompressedTexImage2Dの場合、転送する画像サイズが、テクスチャサイズと同値でないと失敗します。
・VRAMサイズ = 240x320pixel（QVGA）
・テクスチャサイズ = 256x512pixel
という差異があり、テクスチャサイズでしか転送できない場合、倍程度の無駄領域が発生してしまいます。
なので、折角圧縮して転送量が半分になるのに、無駄領域の転送により転送量が倍になる・・・
・・・要するに、完全なる無意味状態。
glCompressedTexSubImage2Dの場合、圧縮形式が通常の
GL_PALETTE8_R5_G6_B5_OESとかではなく、PVRTC方式というGPU内部のアルゴリズムで圧縮しなければなりません。
一応、glext.hに以下の4種類が#defineされています。
#define GL_COMPRESSED_RGB_PVRTC_4BPPV1_IMG 0x8C00
#define GL_COMPRESSED_RGB_PVRTC_2BPPV1_IMG 0x8C01
#define GL_COMPRESSED_RGBA_PVRTC_4BPPV1_IMG 0x8C02
#define GL_COMPRESSED_RGBA_PVRTC_2BPPV1_IMG 0x8C03
で、この圧縮方式ですが、けっこう複雑です。
要するに、GPU内部でこのアルゴリズムでテクスチャ情報を変換して保持しているから、テクスチャイメージの書き換えには膨大な処理時間を持っていかれてしまう訳ですね。
なので、仮に自前のCPU演算で同じ圧縮演算をしたとしても、GPU任せの変換と比較して膨大な処理時間を食う訳です。
という訳で、
ほぼチェックメイトです。
「ほぼ」というのは、まだ２つほど別のアイディアがあるという意味です。
【アイディア１：ベースロジックの改造】
テクスチャ変換処理を完全に別スレッド（非同期）にして、onDrawFrameのサイクルが呼ばれる時点で完成した前フレームのテクスチャを画面に出力する（毎回１フレームの遅延が発生するけど、かなり軽くなる筈）
【アイディア２：総転送量を減らす】
テクスチャを２枚（256x256と256x64にして、組み合わせて256x320にする。
この方式はかなり危険です。
・つなぎ目の境界がボンヤリ見えてしまう可能性がある。
・2回glCompressedTexImage2Dを呼び出す必要がある。
追記5
とりあえず、【アイディア２：総転送量を減らす】を実装してみました。
つなぎ目は割りと気になりません。
しかし、やはり、2回glCompressedTexImage2Dを呼び出すオーバーヘッドが思ったよりも大きい。
一応速くなりましたがね。
IdeaPadA1で、55～56fpsで安定していたものが57～58fpsで安定する程度に。。。
もはや、ギブアップ寸前。。。
やっぱり、OpenGL/ESは使い物にならない。。。
そもそも、ポリゴンのテクスチャとは、頻繁な書き換えを想定したものではないので。
OpenGL/ESで性能を出そうと思えば、パターンデータは完全に固定化する必要があるというのが、結論かな。
しかし、2Dゲームの場合、そんなんだと使い物になりません。。。
ピクセル単位での書き込みや、スプライトのマスキング表示などが必須なので。
それらはパターンデータの加工が必須。
テスクチャを書き換えずに利用する方式だと、パターンデータの加工はできない。
よって、チェックメイト・・・。
ちなみに、onFrameDrawのC側の関数の入口と出口にログ出力処理を入れてみたところ、
I/SHOT04 (16557): 2012/07/15 19:01:37.562 start
I/SHOT04 (16557): 2012/07/15 19:01:37.578 end (
4ms)
I/SHOT04 (16557): 2012/07/15 19:01:37.579 start
I/SHOT04 (16557): 2012/07/15 19:01:37.595 end (
16ms)
I/SHOT04 (16557): 2012/07/15 19:01:37.597 start
I/SHOT04 (16557): 2012/07/15 19:01:37.612 end (
15ms)
I/SHOT04 (16557): 2012/07/15 19:01:37.613 start
I/SHOT04 (16557): 2012/07/15 19:01:37.629 end (
16ms)
I/SHOT04 (16557): 2012/07/15 19:01:37.630 start
I/SHOT04 (16557): 2012/07/15 19:01:37.646 end (16ms)
I/SHOT04 (16557): 2012/07/15 19:01:37.647 start
I/SHOT04 (16557): 2012/07/15 19:01:37.662 end (
15ms)
I/SHOT04 (16557): 2012/07/15 19:01:37.664 start
I/SHOT04 (16557): 2012/07/15 19:01:37.671 end (
7ms)
I/SHOT04 (16557): 2012/07/15 19:01:37.686 start
I/SHOT04 (16557): 2012/07/15 19:01:37.694 end (
8ms)
という具合。
絶望的な遅さです。
何よりバラツキが激しい。
やっぱり、
PVRTCが相当なｸｾﾓﾉです。
完全なソフトウェアレンダリングの方が高速に処理できる気がしてきたので、そっちの方向で探ってみるか。。。
追記6
そもそも、今回の問題の発端になったCanvasがICS（Android4）で劇的に性能劣化するようになった原因のGoogle公式回答が見つかりました。
https://groups.google.com/forum/?fromgroups#!topic/android-developers/CK_jkHEQoOM
Google「
すまんね、lockCanvasはAndroid3以降、ハードウェアアクセラレーションしないよ。」
えっ？
それだけ？
質問している方は、代替策を聞いているのに、代替策に関しては無策ということはバグですね。
ICSからのバグならまだしも、Android3の頃からのバグ（仕様欠陥）ってことは、直す気ナシか？
Googleみたいなスカタンな連中にOSを作らせた結果がコレです。
完全に推測ですが、ICS開発中のGoogle内部でのやりとりは、大方
・電池持ちについて検討
・SurfaceView+CanvasのH/Wアクセラレーションを切れば電池持ちが良くなる
・ゲームが遅くなる可能性については黙認 （デグっても問題なしと判断）
といった感じですかね。
さて、どうしたものか。
Android 2.3専用にして作り続けるか、開発自体をドロップするかの二択？
厳しいなぁ。。。
とりあえず、やる気が大分削げました。
Windowsでゲーム本編の開発を進めることはできるから、作りながら待つべきか。
